[PATCH v3 09/12] libfdt: Add fdt_find_regions()

[Simon Glass]

Add a function to find regions in device tree given a list of nodes to
include and properties to exclude.

See the header file for full documentation.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3: None
Changes in v2:
- Fix checkpatch checks about parenthesis alignment

 include/libfdt.h |  64 +
 lib/libfdt/fdt_wip.c | 129 +++
 2 files changed, 193 insertions(+)

diff --git a/include/libfdt.h b/include/libfdt.h
index c5ec2ac..765d84f 100644
--- a/include/libfdt.h
+++ b/include/libfdt.h
@@ -1511,4 +1511,68 @@ int fdt_del_node(void *fdt, int nodeoffset);
 
 const char *fdt_strerror(int errval);
 
+struct fdt_region {
+   int offset;
+   int size;
+};
+
+/**
+ * fdt_find_regions() - find regions in device tree
+ *
+ * Given a list of nodes to include and properties to exclude, find
+ * the regions of the device tree which describe those included parts.
+ *
+ * The intent is to get a list of regions which will be invariant provided
+ * those parts are invariant. For example, if you request a list of regions
+ * for all nodes but exclude the property data, then you will get the
+ * same region contents regardless of any change to data properties.
+ *
+ * This function can be used to produce a byte-stream to send to a hashing
+ * function to verify that critical parts of the FDT have not changed.
+ *
+ * Nodes which are given in 'inc' are included in the region list, as
+ * are the names of the immediate subnodes nodes (but not the properties
+ * or subnodes of those subnodes).
+ *
+ * For eaxample / means to include the root node, all root properties
+ * and the FDT_BEGIN_NODE and FDT_END_NODE of all subnodes of /. The latter
+ * ensures that we capture the names of the subnodes. In a hashing situation
+ * it prevents the root node from changing at all Any change to non-excluded
+ * properties, names of subnodes or number of subnodes would be detected.
+ *
+ * When used with FITs this provides the ability to hash and sign parts of
+ * the FIT based on different configurations in the FIT. Then it is
+ * impossible to change anything about that configuration (include images
+ * attached to the configuration), but it may be possible to add new
+ * configurations, new images or new signatures within the existing
+ * framework.
+ *
+ * Adding new properties to a device tree may result in the string table
+ * being extended (if the new property names are different from those
+ * already added). This function can optionally include a region for
+ * the string table so that this can be part of the hash too.
+ *
+ * The device tree header is not included in the list.
+ *
+ * @fdt:   Device tree to check
+ * @inc:   List of node paths to included
+ * @inc_count: Number of node paths in list
+ * @exc_prop:  List of properties names to exclude
+ * @exc_prop_count:Number of properties in exclude list
+ * @region:Returns list of regions
+ * @max_region:Maximum length of region list
+ * @path:  Pointer to a temporary string for the function to use for
+ * building path names
+ * @path_len:  Length of path, must be large enough to hold the longest
+ * path in the tree
+ * @add_string_tab:1 to add a region for the string table
+ * @return number of regions in list. If this is max_regions then the
+ * region array was exhausted. You should increase max_regions and try
+ * the call again.
+ */
+int fdt_find_regions(const void *fdt, char * const inc[], int inc_count,
+char * const exc_prop[], int exc_prop_count,
+struct fdt_region region[], int max_regions,
+char *path, int path_len, int add_string_tab);
+
 #endif /* _LIBFDT_H */
diff --git a/lib/libfdt/fdt_wip.c b/lib/libfdt/fdt_wip.c
index 63e67b7..b9e3c4a 100644
--- a/lib/libfdt/fdt_wip.c
+++ b/lib/libfdt/fdt_wip.c
@@ -120,3 +120,132 @@ int fdt_nop_node(void *fdt, int nodeoffset)
endoffset - nodeoffset);
return 0;
 }
+
+#define FDT_MAX_DEPTH  32
+
+static int str_in_list(const char *str, char * const list[], int count)
+{
+   int i;
+
+   for (i = 0; i  count; i++)
+   if (!strcmp(list[i], str))
+   return 1;
+
+   return 0;
+}
+
+int fdt_find_regions(const void *fdt, char * const inc[], int inc_count,
+char * const exc_prop[], int exc_prop_count,
+struct fdt_region region[], int max_regions,
+char *path, int path_len, int add_string_tab)
+{
+   int stack[FDT_MAX_DEPTH];
+   char *end;
+   int nextoffset = 0;
+   uint32_t tag;
+   int count = 0;
+   int start = -1;
+   int depth = -1;
+   int want = 0;
+   int base = fdt_off_dt_struct(fdt);
+
+   end = path;
+   *end = '\0';
+   do {
+   const struct fdt_property *prop;
+   const char *name

Re: [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Simon Glass]

Hi Stephen,

On Tue, May 28, 2013 at 1:57 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 05/28/2013 01:36 PM, Simon Glass wrote:
 There are a few partially conflicting requirements in compiling the device
 tree, since U-Boot relies on whatever is installed on the build machine.

 Some versions of dtc support -i, and this is often better than using #include
 since you get correct line number information in errors.

 What issue is there with line numbers when using dtc? Recent dtc
 supports #line directives from the pre-processing results, and hence
 reports errors in terms of the source files, just like raw dtc without cpp.

That's the issue. What does dtc v1.3 do?


 Unfortunately this
 version must be installed manually in current Linux distributions.

 Well, then that gets into the problem of some .dts files choosing to use
 /include/ and rely on -i, but others using #include and not. I don't
 really think it's a good idea to propagate both versions. Picking one
 and using it would be far better.

 I really do think we should simply require a reasonably recent dtc and
 be done with it.

I would be happy with that, but it can be an extra barrier to getting
U-Boot building. So do we need using #include at all if we are using
-i ?


 Some device tree files use the word 'linux' which gets replaced with '1' by
 many version of gcc, including version 4.7. So undefine this.

 Linux chose to use -undef rather than undefining specific/individual
 defines. It'd be best to be consistent to that .dts files are more
 likely to be portable between the two.

Seems a bit extreme, but OK. Are you worried that gcc defines other
things without the double underscore?


 diff --git a/dts/Makefile b/dts/Makefile

 +# Provide a list of include directories for dtc
 +DTS_INCS-y := -i $(SRCTREE)/arch/$(ARCH)/dts
 +
 +DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts

 That has arch/ first then board/ ... (continued a few comments below)

 +DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts

 Is that meant to be upstream?

 +# Check if our dtc includes the -i option
 +DTS_FLAGS := $(shell if ! dtc -i 21 | grep -q invalid option; then \
 + echo $(DTS_INCS-y); fi)
 +
  # We preprocess the device tree file provide a useful define
 -DTS_CPPFLAGS := -x assembler-with-cpp \
 +# Undefine 'linux' since it might be used in device tree files
 +DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \

 I'll repeat my request to use -undef instead.

   
 -DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\
  \
   
 -DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\ \
 - -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
 + -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \
 + -I$(OBJTREE)/include2 \

 Do we really want include or include2 (what's that?) at all? The .dts
 files really should be standalone, and not interact with the U-Boot
 headers at all.

I understood that you were wanting to make use of U-Boot defines. If
you want to include include/config.h then I think you need these.


 + -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts 
 \

 ... whereas this has board/ first then arch/. It'd be better to be
 consistent.

OK


 + -include $(OBJTREE)/include/config.h
 +
 +DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in

 Hmm. This really isn't a generated header file. Can this instead be
 $(OBJTREE)/$(dir $@).$(notdir $@).dts or something like that?

I didn't say header file.

The nice thing about having everything in include/generated is that it
doesn't pollute the source for in-tree builds.


 +DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts

  all: $(obj).depend $(LIB)

 @@ -50,13 +68,19 @@ all:  $(obj).depend $(LIB)
  # the filename.
  DT_BIN   := $(obj)dt.dtb

 -$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
 +DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS) $(DTS_TMP)

 It may be better to leave $(DTS_TMP) in the make script below, so it's
 more obvious what file is being compiled; the re-direct to $(DTS_TMP) is
 left in the $(CPP) invocation below, so it'd also be consistent with that.

 +$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
   rc=$$( \
 - cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
 - { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
 + cat $ | $(CPP) -P $(DTS_CPPFLAGS) -  $(DTS_TMP); \
 + { { $(DTC_CMD)  21 ; \
 ...

 + if [ $$rc != 0 ]; then \
 + echo Source file is $(DTS_SRC); \
 + echo Compiler: $(DTC_CMD); \
 + fi; \

 Isn't that what make V=1 is for?

It produces about 800KB of other spiel though. If the build fails it
is already printing stuff out - so I find this useful.



Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Simon Glass]

Hi Wolfgang,

On Tue, May 28, 2013 at 2:08 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Simon Glass,

 In message 1369769778-12455-1-git-send-email-...@chromium.org you wrote:

 Some device tree files use the word 'linux' which gets replaced with '1' by
 many version of gcc, including version 4.7. So undefine this.

 I think this is not a good way to address this issue.  The GCC
 documentation (section System-specific Predefined Macros [1])
 desribes how this should be handled.  The correct (TM) way to fix
 this is by adding -ansi or any -std option that requests strict
 conformance to the compiler/preprocessor command line.

 [1] 
 http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros

Stephen suggested a slightly more extreme version too - I was worried
that all the typing stuff in U-Boot headers would break in this case,
but I didn't actually test it, so perhaps it is fine.

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Simon Glass]

Hi,

On Wed, May 29, 2013 at 4:07 PM, Stephen Warren swar...@wwwdotorg.orgwrote:

 On 05/29/2013 04:36 PM, Wolfgang Denk wrote:
  Dear Stephen Warren,
 
  In message 51a67ec1.2000...@wwwdotorg.org you wrote:
 
  To keep this process in check a bit, we could always pick a specific git
  commit or release version of dtc that each U-Boot version (release) will
  be allowed to assume. That will limit the number of times people need to
  update their locally-built dtc to at most once per U-Boot release.
  Hopefully much less often.
 
  I think this is broken by design, in several aspects.  First, U-Boot
  is usually not the only user of DTC.  Second, assume you run a git
  bisect over a U-Boot tree - would you really want to switch DTC in-
  flight?
 
  Sorry, instead we should strive to be compatible to a reasonably old,
  stable version of DTC, like we do for all other tools as well.  As
  mentioned before - just because RHEL 5 ships an ancient version of -
  say - make we will NOT start building this from the sources ourself.
  This cannot be the way to go.

 So the result of that is that we can never ever use new features in any
 tool, at least in any meaningful time-frame.

 I think we need to differentiate between tools that are already stable
 and/or core to all aspects of the U-Boot build process (such as make),
 and tools that enable new features that are under development.

 Clearly the U-Boot makefiles have to be fairly cautious in their use of
 any new make features, so that everyone with any reasonable version of
 make can build U-Boot.

 However, when enabling a new feature, such as using device trees to
 configure U-Boot[1], for which tool support is new and evolving along
 with the feature itself, and which is only used on a very very few
 boards and even fewer SoCs right now within U-Boot, it seems entirely
 reasonable to demand that the people working on/with that new feature
 are aware that it's evolving, and that they may need to take a few extra
 steps to go out and get tools that support that new feature. No doubt
 once this feature has settled down a bit, and distros have pulled in
 newer versions of dtc, everthing will just work just like any other
 stable feature.

 If you don't accept this, then we simply have to ban any include use in
 U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to
 stop using that. We'd need to move *.dts into a single directory within
 U-Boot to work around that, or perhaps hard-coding relative include
 paths in *.dts might work. Similarly for the patches to support dtc+cpp
 usage, so we wouldn't be able to use named constants in DT files for
 many years, which would prevent sharing DT files with the kernel and/or
 any other standard repository of DT files, which are bound to use this
 feature.

 [1] Which is very specifically a different feature than simply having
 U-Boot pass a DT to the Linux kernel during boot, and perhaps modify it
 a little, which clearly is not a new feature.


My patch:

- doesn't require -i but uses it if available (ARCH_CPU_DTS works around
this)
- honours #define, #include, etc.
- works with old and new versions of dtc
- uses -Ulinux which we are thinking might be better done another way

Let's not throw the baby out with the bathwater. I have no problem with
updating my dtc as needed, but it would certainly be nice if U-Boot didn't
require this.

However, let's say Tegra needs a newer dtc than 1.3. I wonder whether we
should just add a setting to tell U-Boot to not build the device tree at
all? The same U-Boot binary can run on many different board times, just
needing a different device tree. Rather than pick one, we could just pick
none. Then if you want to use new features in dtc, just define
CONFIG_OF_NO_BUILD, or similar, and you can deal with the device tree
details yourself. MAKEALL/buildman will be happy with this.

Otherwise for now I think my patch is a reasonable compromise in terms of
features.

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Simon Glass]

Hi Stephen,

On Wed, May 29, 2013 at 10:11 PM, Stephen Warren swar...@wwwdotorg.orgwrote:

 On 05/29/2013 10:46 PM, Simon Glass wrote:
  Hi,
 
  On Wed, May 29, 2013 at 4:07 PM, Stephen Warren swar...@wwwdotorg.org
  mailto:swar...@wwwdotorg.org wrote:
 
  On 05/29/2013 04:36 PM, Wolfgang Denk wrote:
   Dear Stephen Warren,
  
   In message 51a67ec1.2000...@wwwdotorg.org
  mailto:51a67ec1.2000...@wwwdotorg.org you wrote:
  
   To keep this process in check a bit, we could always pick a
  specific git
   commit or release version of dtc that each U-Boot version
  (release) will
   be allowed to assume. That will limit the number of times people
  need to
   update their locally-built dtc to at most once per U-Boot release.
   Hopefully much less often.
  
   I think this is broken by design, in several aspects.  First,
 U-Boot
   is usually not the only user of DTC.  Second, assume you run a git
   bisect over a U-Boot tree - would you really want to switch DTC
 in-
   flight?
  
   Sorry, instead we should strive to be compatible to a reasonably
 old,
   stable version of DTC, like we do for all other tools as well.  As
   mentioned before - just because RHEL 5 ships an ancient version of
 -
   say - make we will NOT start building this from the sources
 ourself.
   This cannot be the way to go.
 
  So the result of that is that we can never ever use new features in
 any
  tool, at least in any meaningful time-frame.
 
  I think we need to differentiate between tools that are already
 stable
  and/or core to all aspects of the U-Boot build process (such as
 make),
  and tools that enable new features that are under development.
 
  Clearly the U-Boot makefiles have to be fairly cautious in their use
 of
  any new make features, so that everyone with any reasonable version
 of
  make can build U-Boot.
 
  However, when enabling a new feature, such as using device trees to
  configure U-Boot[1], for which tool support is new and evolving along
  with the feature itself, and which is only used on a very very few
  boards and even fewer SoCs right now within U-Boot, it seems entirely
  reasonable to demand that the people working on/with that new feature
  are aware that it's evolving, and that they may need to take a few
 extra
  steps to go out and get tools that support that new feature. No doubt
  once this feature has settled down a bit, and distros have pulled in
  newer versions of dtc, everthing will just work just like any other
  stable feature.
 
  If you don't accept this, then we simply have to ban any include use
 in
  U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd
 need to
  stop using that. We'd need to move *.dts into a single directory
 within
  U-Boot to work around that, or perhaps hard-coding relative include
  paths in *.dts might work. Similarly for the patches to support
 dtc+cpp
  usage, so we wouldn't be able to use named constants in DT files for
  many years, which would prevent sharing DT files with the kernel
 and/or
  any other standard repository of DT files, which are bound to use
 this
  feature.
 
  [1] Which is very specifically a different feature than simply having
  U-Boot pass a DT to the Linux kernel during boot, and perhaps modify
 it
  a little, which clearly is not a new feature.
 
 
  My patch:
 
  - doesn't require -i but uses it if available (ARCH_CPU_DTS works around
  this)


I had to remove all sharp objects from the room half-way through reading
your email :-) Gosh, things aren't that bad!



 If we ever need to support a dtc that doesn't implement -i, then we
 always need to support that. So, there's no point using -i when it's
 available; we should simply have a single way of writing the *.dts files
 that doesn't ever assume dtc -i is available. Otherwise, there will be
 rampant inconsistency between different *.dts files; how they're
 written, the flow by which they're compiled, etc.

 In other words, we /always/ have to use ARCH_CPU_DTS in *.dts
 throughout the entire U-Boot source tree if we're to support not using
 dtc -i.


Well realistically at some point there will be a new dtc release, and
perhaps a year or so after that we can maybe start deprecating this and
requiring -i.



  - honours #define, #include, etc.
  - works with old and new versions of dtc

 If we are forced to rely only upon features in old versions of dtc, we
 specifically shouldn't allow use of features that will only work with
 newer dtc. If we don't actively enforce this rule, we haven't achieved
 the goal of not relying upon new versions of dtc.


As you know I'm uncomfortable with the idea of using CPP to do things that
I feel dtc should do for itself, but yes if dtc does not grow these
features, we have little choice. But as an example, both

[PATCH] fdt: Enhance dts/Makefile to be all things to all men

[Simon Glass]

There are a few partially conflicting requirements in compiling the device
tree, since U-Boot relies on whatever is installed on the build machine.

Some versions of dtc support -i, and this is often better than using #include
since you get correct line number information in errors. Unfortunately this
version must be installed manually in current Linux distributions.

Some device tree files use the word 'linux' which gets replaced with '1' by
many version of gcc, including version 4.7. So undefine this.

When an device tree file has an error we want to direct the user to the
right file and line number. So instead of piping the file into dts through
stdin, put it in a real file so that we get a fairly sensible error message
from dts. Then print out the original file details to help further.

This is based on a commit from Tom Warren. It would help if people can
test it in different environments.

Signed-off-by: Tom Warren twar...@nvidia.com
Signed-off-by: Simon Glass s...@chromium.org
---
 dts/Makefile | 34 +-
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/dts/Makefile b/dts/Makefile
index 03e163e..1f6fabb 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -37,11 +37,29 @@ $(if $(CONFIG_ARCH_DEVICE_TREE),,\
 $(error Your architecture does not have device tree support enabled. \
 Please define CONFIG_ARCH_DEVICE_TREE))
 
+# Provide a list of include directories for dtc
+DTS_INCS-y := -i $(SRCTREE)/arch/$(ARCH)/dts
+
+DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts
+
+DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts
+
+# Check if our dtc includes the -i option
+DTS_FLAGS := $(shell if ! dtc -i 21 | grep -q invalid option; then \
+   echo $(DTS_INCS-y); fi)
+
 # We preprocess the device tree file provide a useful define
-DTS_CPPFLAGS := -x assembler-with-cpp \
+# Undefine 'linux' since it might be used in device tree files
+DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \

-DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\ \

-DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\ \
-   -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
+   -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \
+   -I$(OBJTREE)/include2 \
+   -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts \
+   -include $(OBJTREE)/include/config.h
+
+DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in
+DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts
 
 all:   $(obj).depend $(LIB)
 
@@ -50,13 +68,19 @@ all:$(obj).depend $(LIB)
 # the filename.
 DT_BIN := $(obj)dt.dtb
 
-$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
+DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS) $(DTS_TMP)
+
+$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
rc=$$( \
-   cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
-   { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
+   cat $ | $(CPP) -P $(DTS_CPPFLAGS) -  $(DTS_TMP); \
+   { { $(DTC_CMD)  21 ; \
echo $$? 3 ; } | \
  grep -v '^DTC: dts-dtb  on file' ; \
} 31 12 ) ; \
+   if [ $$rc != 0 ]; then \
+   echo Source file is $(DTS_SRC); \
+   echo Compiler: $(DTC_CMD); \
+   fi; \
exit $$rc
 
 process_lds = \
-- 
1.8.2.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [U-Boot] [PATCH v4 0/19] Allow images to work on sandbox

[Simon Glass]

Hi Tom,

On Thu, May 9, 2013 at 12:36 PM, Tom Rini tr...@ti.com wrote:
 On Tue, May 07, 2013 at 09:11:44AM -0700, Simon Glass wrote:

 This series adjusts the image code to work with sandbox and prepares it for
 verified boot to come later.

 The primary goal here is to get image loading to work on sandbox, which is
 mostly a set of fairly minor changes such as using map_sysmem() instead of
 just a cast when converting from a U-Boot address to a pointer. Since
 common/image.c runs to over 3000 lines and half of it is FIT-related code
 behind an #ifdef, this code is moved into a new image-fit.c file.

 Changes in v4:
 - Bring in upstream version of fdt_first/next_subnode()
 - Use new upstream fdt_first/next_subnode()

 Everything looks fine to me, barring further comments I'll pick this up
 around next Tuesday.

Thanks, The next series to hopefully improve image support is queued
up, and I will get the final one done also.

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v4 0/19] Allow images to work on sandbox

[Simon Glass]

This series adjusts the image code to work with sandbox and prepares it for
verified boot to come later.

The primary goal here is to get image loading to work on sandbox, which is
mostly a set of fairly minor changes such as using map_sysmem() instead of
just a cast when converting from a U-Boot address to a pointer. Since
common/image.c runs to over 3000 lines and half of it is FIT-related code
behind an #ifdef, this code is moved into a new image-fit.c file.

Changes in v4:
- Bring in upstream version of fdt_first/next_subnode()
- Use new upstream fdt_first/next_subnode()

Changes in v3:
- Split out image improvements into a separate series
- Update notes to note that generic board support has now landed

Changes in v2:
- Add IMAGE_ENABLE_IGNORE to avoid #ifdef around ignore property handling
- Change hash_block() to use an unsigned int len
- Clarify use of output_size parameter to hash_block()
- Fix checkpatch checks about parenthesis alignment
- Fix line continuation problem
- Put err_msgp strings on a single line
- Put params before description in fit_conf_get_prop_node() comment
- Rebase on previous patches
- Rename commit message to say function instead of function

Simon Glass (19):
  env: Fix minor comment typos in cmd_nvedit
  Add minor updates to README.fdt-control
  hash: Add a way to calculate a hash for any algortihm
  bootstage: Don't build for HOSTCC
  mkimage: Move ARRAY_SIZE to header file
  libfdt: Add fdt_next_subnode() to permit easy subnode iteration
  image: Move timestamp #ifdefs to header file
  image: Export fit_check_ramdisk()
  image: Split FIT code into new image-fit.c
  image: Move HOSTCC image code to tools/
  image: Split hash node processing into its own function
  image: Convert fit_image_hash_set_value() to static, and rename
  image: Rename fit_image_check_hashes() to fit_image_verify()
  image: Move hash checking into its own function
  image: Move error! string to common place
  image: Export fit_conf_get_prop_node()
  image: Rename fit_add_hashes() to fit_add_verification_data()
  image: Rename hash printing to fit_image_print_verification_data()
  sandbox: image: Add support for booting images in sandbox

 common/Makefile|1 +
 common/cmd_bootm.c |   25 +-
 common/cmd_fpga.c  |2 +-
 common/cmd_nvedit.c|4 +-
 common/cmd_source.c|2 +-
 common/cmd_ximg.c  |2 +-
 common/hash.c  |   23 +
 common/image-fit.c | 1495 ++
 common/image.c | 1679 ++--
 common/update.c|2 +-
 doc/README.fdt-control |9 +-
 include/bootstage.h|5 +-
 include/hash.h |   22 +
 include/image.h|   55 +-
 include/libfdt.h   |   22 +
 lib/libfdt/fdt.c   |   28 +
 tools/Makefile |4 +
 tools/aisimage.c   |1 -
 tools/fit_image.c  |2 +-
 tools/image-host.c |  208 ++
 tools/mkimage.h|2 +
 21 files changed, 1917 insertions(+), 1676 deletions(-)
 create mode 100644 common/image-fit.c
 create mode 100644 tools/image-host.c

-- 
1.8.2.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v4 06/19] libfdt: Add fdt_next_subnode() to permit easy subnode iteration

[Simon Glass]

Iterating through subnodes with libfdt is a little painful to write as we
need something like this:

for (depth = 0, count = 0,
offset = fdt_next_node(fdt, parent_offset, depth);
 (offset = 0)  (depth  0);
 offset = fdt_next_node(fdt, offset, depth)) {
if (depth == 1) {
/* code body */
}
}

Using fdt_next_subnode() we can instead write this, which is shorter and
easier to get right:

for (offset = fdt_first_subnode(fdt, parent_offset);
 offset = 0;
 offset = fdt_next_subnode(fdt, offset)) {
/* code body */
}

Also, it doesn't require two levels of indentation for the loop body.

Signed-off-by: Simon Glass s...@chromium.org
(Cherry-picked from dtc commit 4e76ec79)
---
Changes in v4:
- Bring in upstream version of fdt_first/next_subnode()

Changes in v3: None
Changes in v2: None

 include/libfdt.h | 22 ++
 lib/libfdt/fdt.c | 28 
 2 files changed, 50 insertions(+)

diff --git a/include/libfdt.h b/include/libfdt.h
index fc7f75b..3721a90 100644
--- a/include/libfdt.h
+++ b/include/libfdt.h
@@ -136,6 +136,28 @@ uint32_t fdt_next_tag(const void *fdt, int offset, int 
*nextoffset);
 
 int fdt_next_node(const void *fdt, int offset, int *depth);
 
+/**
+ * fdt_first_subnode() - get offset of first direct subnode
+ *
+ * @fdt:   FDT blob
+ * @offset:Offset of node to check
+ * @return offset of first subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+int fdt_first_subnode(const void *fdt, int offset);
+
+/**
+ * fdt_next_subnode() - get offset of next direct subnode
+ *
+ * After first calling fdt_first_subnode(), call this function repeatedly to
+ * get direct subnodes of a parent node.
+ *
+ * @fdt:   FDT blob
+ * @offset:Offset of previous subnode
+ * @return offset of next subnode, or -FDT_ERR_NOTFOUND if there are no more
+ * subnodes
+ */
+int fdt_next_subnode(const void *fdt, int offset);
+
 /**/
 /* General functions  */
 /**/
diff --git a/lib/libfdt/fdt.c b/lib/libfdt/fdt.c
index 387e354..154e9a4 100644
--- a/lib/libfdt/fdt.c
+++ b/lib/libfdt/fdt.c
@@ -202,6 +202,34 @@ int fdt_next_node(const void *fdt, int offset, int *depth)
return offset;
 }
 
+int fdt_first_subnode(const void *fdt, int offset)
+{
+   int depth = 0;
+
+   offset = fdt_next_node(fdt, offset, depth);
+   if (offset  0 || depth != 1)
+   return -FDT_ERR_NOTFOUND;
+
+   return offset;
+}
+
+int fdt_next_subnode(const void *fdt, int offset)
+{
+   int depth = 1;
+
+   /*
+* With respect to the parent, the depth of the next subnode will be
+* the same as the last.
+*/
+   do {
+   offset = fdt_next_node(fdt, offset, depth);
+   if (offset  0 || depth  1)
+   return -FDT_ERR_NOTFOUND;
+   } while (depth  1);
+
+   return offset;
+}
+
 const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
 {
int len = strlen(s) + 1;
-- 
1.8.2.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v2] libfdt: Add fdt_next_subnode() to permit easy subnode iteration

[Simon Glass]

Iterating through subnodes with libfdt is a little painful to write as we
need something like this:

for (depth = 0, count = 0,
offset = fdt_next_node(fdt, parent_offset, depth);
 (offset = 0)  (depth  0);
 offset = fdt_next_node(fdt, offset, depth)) {
if (depth == 1) {
/* code body */
}
}

Using fdt_next_subnode() we can instead write this, which is shorter and
easier to get right:

for (offset = fdt_first_subnode(fdt, parent_offset);
 offset = 0;
 offset = fdt_next_subnode(fdt, offset)) {
/* code body */
}

Also, it doesn't require two levels of indentation for the loop body.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Use first/next pattern to avoid needing a depth parameter

 libfdt/fdt.c  | 28 ++
 libfdt/libfdt.h   | 22 +++
 tests/Makefile.tests  |  3 +-
 tests/run_tests.sh|  3 ++
 tests/subnode_iterate.c   | 94 +++
 tests/subnode_iterate.dts | 44 ++
 6 files changed, 193 insertions(+), 1 deletion(-)
 create mode 100644 tests/subnode_iterate.c
 create mode 100644 tests/subnode_iterate.dts

diff --git a/libfdt/fdt.c b/libfdt/fdt.c
index 57faba3..2ce6a44 100644
--- a/libfdt/fdt.c
+++ b/libfdt/fdt.c
@@ -198,6 +198,34 @@ int fdt_next_node(const void *fdt, int offset, int *depth)
return offset;
 }
 
+int fdt_first_subnode(const void *fdt, int offset)
+{
+   int depth = 0;
+
+   offset = fdt_next_node(fdt, offset, depth);
+   if (offset  0 || depth != 1)
+   return -FDT_ERR_NOTFOUND;
+
+   return offset;
+}
+
+int fdt_next_subnode(const void *fdt, int offset)
+{
+   int depth = 1;
+
+   /*
+* With respect to the parent, the depth of the next subnode will be
+* the same as the last.
+*/
+   do {
+   offset = fdt_next_node(fdt, offset, depth);
+   if (offset  0 || depth  1)
+   return -FDT_ERR_NOTFOUND;
+   } while (depth  1);
+
+   return offset;
+}
+
 const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
 {
int len = strlen(s) + 1;
diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
index 130789a..02baa84 100644
--- a/libfdt/libfdt.h
+++ b/libfdt/libfdt.h
@@ -136,6 +136,28 @@ uint32_t fdt_next_tag(const void *fdt, int offset, int 
*nextoffset);
 
 int fdt_next_node(const void *fdt, int offset, int *depth);
 
+/**
+ * fdt_first_subnode() - get offset of first direct subnode
+ *
+ * @fdt:   FDT blob
+ * @offset:Offset of node to check
+ * @return offset of first subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+int fdt_first_subnode(const void *fdt, int offset);
+
+/**
+ * fdt_next_subnode() - get offset of next direct subnode
+ *
+ * After first calling fdt_first_subnode(), call this function repeatedly to
+ * get direct subnodes of a parent node.
+ *
+ * @fdt:   FDT blob
+ * @offset:Offset of previous subnode
+ * @return offset of next subnode, or -FDT_ERR_NOTFOUND if there are no more
+ * subnodes
+ */
+int fdt_next_subnode(const void *fdt, int offset);
+
 /**/
 /* General functions  */
 /**/
diff --git a/tests/Makefile.tests b/tests/Makefile.tests
index d59bff8..dafb618 100644
--- a/tests/Makefile.tests
+++ b/tests/Makefile.tests
@@ -20,7 +20,8 @@ LIB_TESTS_L = get_mem_rsv \
dtb_reverse dtbs_equal_unordered \
add_subnode_with_nops path_offset_aliases \
utilfdt_test \
-   integer-expressions
+   integer-expressions \
+   subnode_iterate
 LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
 
 LIBTREE_TESTS_L = truncated_property
diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index b56b626..b013761 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -241,6 +241,9 @@ libfdt_tests () {
tree1_tests_rw noppy.$basetree
 done
 
+run_dtc_test -I dts -O dtb -o subnode_iterate.dtb subnode_iterate.dts
+run_test subnode_iterate subnode_iterate.dtb
+
 # Tests for behaviour on various sorts of corrupted trees
 run_test truncated_property
 
diff --git a/tests/subnode_iterate.c b/tests/subnode_iterate.c
new file mode 100644
index 000..b9f379d
--- /dev/null
+++ b/tests/subnode_iterate.c
@@ -0,0 +1,94 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Tests that fdt_next_subnode() works as expected
+ *
+ * Copyright (C) 2013 Google, Inc
+ *
+ * Copyright (C) 2007 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed

Re: [PATCH v8 0/3] Runtime Interpreted Power Sequences

[Simon Glass]

Hi,

On Thu, Nov 15, 2012 at 10:38 PM, Alexandre Courbot acour...@nvidia.com wrote:
 Hopefully the final series before the feature gets merged. Anton Vorontsov
 kindly accepted to take it into his tree, so this series is mostly a call for
 acks, tests and reviews notices before the merge window for 3.8 opens. If you
 are interested in seeing this feature, please add your name.

 This series also adds an entry for the subsystem into MAINTAINERS, setting me 
 as
 the person in charge.

 Changes from v7:
 - fix bug reported by Tony Prisk
 - add MAINTAINERS entry

 Alexandre Courbot (3):
   Runtime Interpreted Power Sequences
   pwm_backlight: use power sequences
   Take maintainership of power sequences

Did this actually land? I can't see it in linux-next.

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH] libfdt: Add fdt_next_subnode() to permit easy subnode iteration

[Simon Glass]

Iterating through subnodes with libfdt is a little painful to write as we
need something like this:

for (depth = 0, count = 0,
offset = fdt_next_node(fdt, parent_offset, depth);
 (offset = 0)  (depth  0);
 offset = fdt_next_node(fdt, offset, depth)) {
if (depth == 1) {
/* code body */
}
}

Using fdt_next_subnode() we can instead write this, which is shorter and
easier to get right:

for (depth = 0, offset = fdt_next_subnode(fdt, parent_offset, depth);
 offset = 0;
 offset = fdt_next_subnode(fdt, offset, depth)) {
/* code body */
}

Also, it doesn't require two levels of indentation for the loop body.

Signed-off-by: Simon Glass s...@chromium.org
---
 libfdt/fdt.c  | 12 ++
 libfdt/libfdt.h   | 17 +
 tests/Makefile.tests  |  3 +-
 tests/run_tests.sh|  3 ++
 tests/subnode_iterate.c   | 97 +++
 tests/subnode_iterate.dts | 44 +
 6 files changed, 175 insertions(+), 1 deletion(-)
 create mode 100644 tests/subnode_iterate.c
 create mode 100644 tests/subnode_iterate.dts

diff --git a/libfdt/fdt.c b/libfdt/fdt.c
index 57faba3..9433f38 100644
--- a/libfdt/fdt.c
+++ b/libfdt/fdt.c
@@ -198,6 +198,18 @@ int fdt_next_node(const void *fdt, int offset, int *depth)
return offset;
 }
 
+int fdt_next_subnode(const void *fdt, int offset, int *depth)
+{
+   /* Loop until we find a direct child of the parent (depth == 1) */
+   do {
+   offset = fdt_next_node(fdt, offset, depth);
+   if (offset  0 || *depth  1)
+   return -FDT_ERR_NOTFOUND;
+   } while (*depth  1);
+
+   return offset;
+}
+
 const char *_fdt_find_string(const char *strtab, int tabsize, const char *s)
 {
int len = strlen(s) + 1;
diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
index 130789a..edd5488 100644
--- a/libfdt/libfdt.h
+++ b/libfdt/libfdt.h
@@ -136,6 +136,23 @@ uint32_t fdt_next_tag(const void *fdt, int offset, int 
*nextoffset);
 
 int fdt_next_node(const void *fdt, int offset, int *depth);
 
+/**
+ * fdt_next_subnode() - get offset of next direct subnode
+ *
+ * Set depth to 0, offset to parent, then call this function repeatedly
+ * to get direct subnodes of a parent node.
+ *
+ * @fdt:   FDT blob
+ * @offset:Set this to offset of parent for the first call. For
+ * subsquent calls, pass in the value returns from the last
+ * call.
+ * @depth: Used internally to monitor depth - set this to 0 for the
+ * first call.
+ * @return offset of next subnode, or -FDT_ERR_NOTFOUND if there are no more
+ * subnodes
+ */
+int fdt_next_subnode(const void *fdt, int offset, int *depth);
+
 /**/
 /* General functions  */
 /**/
diff --git a/tests/Makefile.tests b/tests/Makefile.tests
index d59bff8..dafb618 100644
--- a/tests/Makefile.tests
+++ b/tests/Makefile.tests
@@ -20,7 +20,8 @@ LIB_TESTS_L = get_mem_rsv \
dtb_reverse dtbs_equal_unordered \
add_subnode_with_nops path_offset_aliases \
utilfdt_test \
-   integer-expressions
+   integer-expressions \
+   subnode_iterate
 LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
 
 LIBTREE_TESTS_L = truncated_property
diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index b56b626..b013761 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -241,6 +241,9 @@ libfdt_tests () {
tree1_tests_rw noppy.$basetree
 done
 
+run_dtc_test -I dts -O dtb -o subnode_iterate.dtb subnode_iterate.dts
+run_test subnode_iterate subnode_iterate.dtb
+
 # Tests for behaviour on various sorts of corrupted trees
 run_test truncated_property
 
diff --git a/tests/subnode_iterate.c b/tests/subnode_iterate.c
new file mode 100644
index 000..9a36bb6
--- /dev/null
+++ b/tests/subnode_iterate.c
@@ -0,0 +1,97 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Tests that fdt_next_subnode() works as expected
+ *
+ * Copyright (C) 2013 Google, Inc
+ *
+ * Copyright (C) 2007 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth

Re: [PATCH v2 1/3] libfdt: Add function to find regions in an FDT

[Simon Glass]

Hi David,

On Fri, Mar 22, 2013 at 6:18 AM, David Gibson
da...@gibson.dropbear.id.au wrote:
 On Tue, Mar 12, 2013 at 08:46:12PM -0700, Simon Glass wrote:
 Hi,

 On Fri, Feb 15, 2013 at 2:49 PM, Simon Glass s...@chromium.org wrote:
  Given a set of nodes and properties, find the regions of the device tree
  which describe those parts.
 
  A test is provided which builds a tree while tracking where the regions
  should be, then calls fdt_first/next_region() to make sure that it agrees.
 
  Further tests will come as part of fdtgrep.
 
  Signed-off-by: Simon Glass s...@chromium.org

 I just wondered if there any any comments on this new version?

 Ugh, sorry.  I've been tied up.  From the little I've glanced over it,
 I'm still having trouble getting a coherent feel for the overall
 concept :/

OK I can perhaps write a summary if you give me an idea what I need to
address. Perhaps it is best to look at this by playing with 'fdtgrep'
and seeing how it behaves?

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Simon Glass]

HI Wolfram,

On Wed, Apr 3, 2013 at 12:19 PM, Wolfram Sang w...@the-dreams.de wrote:
 Doug,

 Separately from a discussion of the technical merits, I'd say that
 this patch is needed because the Embedded Controller (EC) on the ARM
 Chromebook shipped expecting to communicate with this scheme.  While

 Uhrm, with all respect, we already shipped it is not a convincing
 argument regarding inclusion. Benefit for the kernel is.

 ...but we can also talk technical merits.  One person on our team
 spent a bit of time thinking about this and decided that traditional
 i2c arbitration can't actually be used in this case (aside from the

 The details would be extremly interesting here. I am very interested in
 this and will ask a few questions further on. This is to get a better
 undestanding for the situation regarding multi-master and what is
 needed, because I expect some demand for it in the near future.

 general experience about multimaster being buggy).  Specifically, our

 I'm also interested in these experiences.

Thanks for coming back on this. Please see my comments below.


 The problem here is that the EC is both a master and a slave.  It's my
 understanding that if the AP tries to talk EC on the bus at the same
 time that the EC is trying to talk to the battery of PMU that we can
 get into trouble.

 If I understand correctly, the I2C Specs mention this case explicitly:

 If a master also incorporates a slave function and it loses arbitration
 during the addressing stage, it is possible that the winning master is
 trying to address it. The losing master must therefore switch over
 immediately to its slave mode.

This seems pretty complicated - does the EC then need to compare the
address it was sending with the remaining bits that are to be received
in that address?

Anyway yes we did consider this case at the time, and the STM32
datasheet had mention of it. But it adds quite a bit of complexity. I
think the start sequence is intended to make this all work, at least
in theory, but it seemed risky to rely on it.

The practical problem here is that in my experience the I2C
multi-master feature is lightly used in practice, and is quite tricky
to get right. That experience was shared with other engineers in the
team, and no one was willing to take the risk on getting everything
running perfectly with i2c multi-master, or doing it on a tight
timeline. I suspect this same problem has arisen many times before,
and will arise again, so from that point of view this feature is a
useful addition to the kernel.

If you are interested in specific experiences then I might be able to
collect some comments from people here. For myself I have found that
getting a reliable I2C driver at all is a sufficient challenge and
time sink with many embedded chips. My memory is a little vague now,
but I know that in 2-3 projects we had to use bit-bash due to bugs or
insufficient documentation in the chip's dedicated I2C peripheral. One
project which had multi-master used a retry scheme with sequenced
packets which seemed to work well enough (i.e. adding a layer above
the I2C layer to sort out problems). The snow project was more
challenging on the I2C  ront, due to the critical nature of I2C buses
in the device.

For snow we found that the Exynos driver did not support arbitration
loss, the STM32 driver we had did not support it, the STM32F I2C
errata indicated problems with I2C in general which reduced our
confidence, and we were unable to determine whether the slave devices
on the bus (smart battery and pmic) would definitely do the right
thing (both chips had I2C issues which we were tracking). I am not
trying to point fingers here, and certainly anything can be solved
given sufficient persistence...but keeping to common features that are
well-tested and available is prudent. As it was we spent more time on
I2C drivers than I would like, and you can get a feel for that in the
Chromium bug tracker if you wish.

Again, I don't believe this would be an unusual situation in a product
development. We need to consider the risk and cost of an approach,
rather than just whether it is technically possible.

From the point of view of arbitration, the two critical points in the
I2C transfer are claiming the bus (detecting that the start condition
failed) and detecting loss of arbitration during a transfer. These
points need to be tested and validated on all master devices, which
can add a considerable burden. Silicon and driver bugs may make this
even more onerous and in fact for some non-compliant implementations
it simply might not work, or might not work reliably.

Please don't take this as a negative view of I2C in general, which is
an excellent bus, unmatched for what it was designed in my view.


 Specifically the EC needs to be switched to master
 mode to talk to the battery/PMU and thus has a period of time where
 it won't be listening for the AP's messages.

 When it talks to the battery, the bus is busy and the EC will not be
 

Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support

[Simon Glass]

Hi Samuel,

On Wed, Mar 20, 2013 at 1:52 AM, Samuel Ortiz sa...@linux.intel.com wrote:
 Hi Simon,

 On Wed, Mar 20, 2013 at 09:14:56AM +0100, Samuel Ortiz wrote:
 On Tue, Mar 19, 2013 at 07:01:42PM -0700, Simon Glass wrote:
  Hi Samuel,
 
  On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz sa...@linux.intel.com 
  wrote:
   On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
   Hi Simon,
  
   On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
The ChromeOS Embedded Controller (EC) is an Open Source EC 
implementation
used on ARM and Intel Chromebooks. Current implementations use a 
Cortex-M3
connected on a bus (such as I2C, SPI, LPC) to the AP. A separate 
interrupt
line is used to indicate when the EC needs service.
   All 6 patches applied to my mfd-next tree, thanks a lot.
   Actually, this one fails to build when CONFIG_OF is not set:
  
   drivers/mfd/cros_ec_i2c.c:130:2: error: implicit declaration of function
   ‘of_device_is_available’ [-Werror=implicit-function-declaration]
  
   If the check in cros_ec_probe_i2c() is really needed then you'll need to 
   inline
   of_device_is_available() into a NOP in include/linux/of.h.
 
  Actually I suppose that call is not really needed. Would you like to
  remove it, or shall I send a new patch?
 I will remove it.
 This is fixed and pushed. I also fixed some warnings and another build failure
 for the case when all of your code is modular.

Thank you for that. I don't think I quite understood the different
build tests that I needed to do.

Regards,
Simon


 Cheers,
 Samuel.

 --
 Intel Open Source Technology Centre
 http://oss.intel.com/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support

[Simon Glass]

Hi Samuel,

On Tue, Mar 19, 2013 at 6:12 PM, Samuel Ortiz sa...@linux.intel.com wrote:
 On Wed, Mar 20, 2013 at 01:56:52AM +0100, Samuel Ortiz wrote:
 Hi Simon,

 On Mon, Feb 25, 2013 at 02:08:35PM -0800, Simon Glass wrote:
  The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
  used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
  connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
  line is used to indicate when the EC needs service.
 All 6 patches applied to my mfd-next tree, thanks a lot.
 Actually, this one fails to build when CONFIG_OF is not set:

 drivers/mfd/cros_ec_i2c.c:130:2: error: implicit declaration of function
 ‘of_device_is_available’ [-Werror=implicit-function-declaration]

 If the check in cros_ec_probe_i2c() is really needed then you'll need to 
 inline
 of_device_is_available() into a NOP in include/linux/of.h.

Actually I suppose that call is not really needed. Would you like to
remove it, or shall I send a new patch?

Regards,
Simon


 Cheers,
 Samuel.

 --
 Intel Open Source Technology Centre
 http://oss.intel.com/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support

[Simon Glass]

Hi Samuel,

On Wed, Feb 27, 2013 at 12:40 AM, Samuel Ortiz sa...@linux.intel.com wrote:
 Hi Simon,

 On Tue, Feb 26, 2013 at 09:13:06PM -0800, Simon Glass wrote:
 Hi Samuel,

 On Mon, Feb 25, 2013 at 2:08 PM, Simon Glass s...@chromium.org wrote:
  The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
  used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
  connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
  line is used to indicate when the EC needs service.
 
  Functions performed by the EC vary by platform, but typically include
  battery charging, keyboard scanning and power sequencing.
 
  This series includes support for the EC message protocol, and implements
  a matrix keyboard handler for Linux using the protocol. The EC performs
  key scanning and passes scan data in response to AP requests. This is
  used on the Samsung ARM Chromebook. No driver is available for LPC at
  present.
 
  This series can in principle operate on any hardware, but for it to 
  actually
  work on the Samsung ARM Chromebook, it needs patches which are currently in
  progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.
 
  The driver is device-tree-enabled and a suitable binding is included in
  this series. Example device tree nodes are included in the examples,
  but no device tree patch for exynos5250-snow is provided at this stage, 
  since
  we must wait for the above-mentioned patches to land to avoid errors from
  dtc. This can be added with a follow-on patch when that work is complete.
 

 Are you happy with this series? Do you think it is ready to be picked
 up for mfd?
 It probably is, and it will be part of the next merge window. I'll apply the
 after the merge window closes.

I'm just checking that we are still good to do this?

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 1/3] libfdt: Add function to find regions in an FDT

[Simon Glass]

Hi,

On Fri, Feb 15, 2013 at 2:49 PM, Simon Glass s...@chromium.org wrote:
 Given a set of nodes and properties, find the regions of the device tree
 which describe those parts.

 A test is provided which builds a tree while tracking where the regions
 should be, then calls fdt_first/next_region() to make sure that it agrees.

 Further tests will come as part of fdtgrep.

 Signed-off-by: Simon Glass s...@chromium.org

I just wondered if there any any comments on this new version?

 ---
 Changes in v2:
 - Move region code to separate fdt_region.c file
 - Fix info-count = info-max_regions in fdt_add_region() merge case
 - Add new FDT_ERR_TOODEEP error type and use it
 - Change returned error from BADLAYOUT to BADSTRUCTURE
 - Return FDT_ERR_BADLAYOUT error if strings block is before structure block
 - Add note that changes in node/property order can cause false hash misses
 - Add more comments about the -1 return value from h_include
 - Drop FDT_IS_COMPAT and pass node offset to h_include function
 - Drop stale comment about names / wildcards
 - Move to a model with fdt_first_region()/fdt_next_region()
 - Add long comment explaining theory of operation

  libfdt/Makefile.libfdt |   3 +-
  libfdt/fdt_region.c| 452 
 +
  libfdt/libfdt.h| 213 ++-
  tests/.gitignore   |   1 +
  tests/Makefile.tests   |   3 +-
  tests/region_tree.c| 336 
  tests/run_tests.sh |   5 +
  7 files changed, 1010 insertions(+), 3 deletions(-)
  create mode 100644 libfdt/fdt_region.c
  create mode 100644 tests/region_tree.c


Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support

[Simon Glass]

Hi Samuel,

On Wed, Feb 27, 2013 at 12:40 AM, Samuel Ortiz sa...@linux.intel.com wrote:
 Hi Simon,

 On Tue, Feb 26, 2013 at 09:13:06PM -0800, Simon Glass wrote:
 Hi Samuel,

 On Mon, Feb 25, 2013 at 2:08 PM, Simon Glass s...@chromium.org wrote:
  The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
  used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
  connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
  line is used to indicate when the EC needs service.
 
  Functions performed by the EC vary by platform, but typically include
  battery charging, keyboard scanning and power sequencing.
 
  This series includes support for the EC message protocol, and implements
  a matrix keyboard handler for Linux using the protocol. The EC performs
  key scanning and passes scan data in response to AP requests. This is
  used on the Samsung ARM Chromebook. No driver is available for LPC at
  present.
 
  This series can in principle operate on any hardware, but for it to 
  actually
  work on the Samsung ARM Chromebook, it needs patches which are currently in
  progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.
 
  The driver is device-tree-enabled and a suitable binding is included in
  this series. Example device tree nodes are included in the examples,
  but no device tree patch for exynos5250-snow is provided at this stage, 
  since
  we must wait for the above-mentioned patches to land to avoid errors from
  dtc. This can be added with a follow-on patch when that work is complete.
 

 Are you happy with this series? Do you think it is ready to be picked
 up for mfd?
 It probably is, and it will be part of the next merge window. I'll apply the
 after the merge window closes.

Thank you.

Regards,
Simon


 Cheers,
 Samuel.

 --
 Intel Open Source Technology Centre
 http://oss.intel.com/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 3/3] RFC: Check offset in fdt_string()

[Simon Glass]

Hi David,

On Thu, Feb 21, 2013 at 3:35 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
 On Fri, Feb 15, 2013 at 02:49:38PM -0800, Simon Glass wrote:
 (We probably don't want this patch, and certainly can't apply it as is,
 but I send it in order to find out the intent of fdt_string()).

 At present fdt_string() says that returns:

- a pointer to the string, on success
- NULL, if stroffset is out of bounds

 However it does not in fact return NULL. Changing it to do so also
 breaks 15 tests (segfault).

 What is the intended behaviour of this function, please?

 Ah.  Yes.  So I'm guessing the tests that fail are all the tests of
 the sequential write functions (fdt_sw.c).  When the blob is in
 sequential write mode, the string offsets work differently - they're
 negative from a strings block pointer which sits at the end of the
 strings.  That's because as we add new properties, the strings block
 grows downwards.  The offsets get fixed up again in fdt_finish().

 So, fdt_string() would need a special case for trees in SW mode.  I
 also have a vague recollection that there was another reason I didn't
 implement the bounds checking, but I seem to have forgotton what it
 was :(.

OK, let's not worry about it for now - this patch should not be applied.

If you think we should / could take particular action, please let me
know and I can perhaps prepare a patch.

Regards,
Simon



 Signed-off-by: Simon Glass s...@chromium.org
 ---
 Changes in v2:
 - Drop patch to replace fdtdump

  libfdt/fdt_ro.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/libfdt/fdt_ro.c b/libfdt/fdt_ro.c
 index 50007f6..cba8772 100644
 --- a/libfdt/fdt_ro.c
 +++ b/libfdt/fdt_ro.c
 @@ -77,6 +77,8 @@ static int _fdt_nodename_eq(const void *fdt, int offset,

  const char *fdt_string(const void *fdt, int stroffset)
  {
 + if (stroffset  0 || stroffset = fdt_size_dt_strings(fdt))
 + return NULL;
   return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
  }


 --
 David Gibson| I'll have my music baroque, and my code
 david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
 | _way_ _around_!
 http://www.ozlabs.org/~dgibson
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v6 0/6] Add ChromeOS Embedded Controller support

[Simon Glass]

Hi Samuel,

On Mon, Feb 25, 2013 at 2:08 PM, Simon Glass s...@chromium.org wrote:
 The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
 used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
 connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
 line is used to indicate when the EC needs service.

 Functions performed by the EC vary by platform, but typically include
 battery charging, keyboard scanning and power sequencing.

 This series includes support for the EC message protocol, and implements
 a matrix keyboard handler for Linux using the protocol. The EC performs
 key scanning and passes scan data in response to AP requests. This is
 used on the Samsung ARM Chromebook. No driver is available for LPC at
 present.

 This series can in principle operate on any hardware, but for it to actually
 work on the Samsung ARM Chromebook, it needs patches which are currently in
 progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.

 The driver is device-tree-enabled and a suitable binding is included in
 this series. Example device tree nodes are included in the examples,
 but no device tree patch for exynos5250-snow is provided at this stage, since
 we must wait for the above-mentioned patches to land to avoid errors from
 dtc. This can be added with a follow-on patch when that work is complete.


Are you happy with this series? Do you think it is ready to be picked
up for mfd?

Regards,
Simon

 Changes in v6:
 - Allow cros_ec to be a module
 - Remove 'struct i2c_msg' definition
 - Use %ph instead of for loop to output packet trace
 - Fix incorrect indentation in cros_ec_keyb_process()
 - Remove unnecessary assignment to NULL in probe function

 Changes in v5:
 - Remove cros_ec allocation functions
 - Remove name access functions in cros_ec, using strings instead
 - Fix Kconfig help message for MFD_CROS_EC_I2C
 - Remove I2C retry logic
 - Switch cros_ec_i2c driver to use devm
 - Update cros_ec_i2c to work with new cros_ec interface
 - Switch cros_ec_spi driver to use devm
 - Update cros_ec_spi to work with new cros_ec interface
 - Fix {} style nit in cros_ec_keyb_has_ghosting
 - Correct key lookup logic which was broken in previous version
 - Switch cros_ec_keyb driver to use devm

 Changes in v4:
 - Fix up trvial logging comments
 - Remove messages reporting out of memory
 - Add compatible string for cros-ec-keyb
 - Remove wake notifier and let drivers use their own handlers instead
 - Add 'depends on MFD_CROS_EC' to Kconfig
 - Remove use of wake_notifier
 - Remove manual code to locate device tree node
 - Add resume handler to clear keyboard scan buffer if required

 Changes in v3:
 - Add stub for matrix_keypad_parse_of_params() when no CONFIG_OF
 - Put back full DT range checking in tca8418 driver
 - Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
 - Remove old_state by using input layer's idev-key
 - Move inner loop of cros_ec_keyb_has_ghosting() into its own function and 
 simplify
 - Add check for not finding the device tree node
 - Remove comment about leaking matrix_keypad_build_keymap()
 - Use platform_get_drvdata() where possible
 - Remove call to input_free_device() after input_unregister_device()

 Changes in v2:
 - Remove use of __devinit/__devexit
 - Remove use of __devinit/__devexit
 - Remove use of __devinit/__devexit
 - Add new patch to decode matrix-keypad DT binding
 - Remove use of __devinit/__devexit
 - Use function to read matrix-keypad parameters from DT
 - Remove key autorepeat parameters from DT binding and driver
 - Use unsigned int for rows/cols

 Simon Glass (6):
   mfd: Add ChromeOS EC messages header
   mfd: Add ChromeOS EC implementation
   mfd: Add ChromeOS EC I2C driver
   mfd: Add ChromeOS EC SPI driver
   Input: matrix-keymap: Add function to read the new DT binding
   Input: Add ChromeOS EC keyboard driver

  .../devicetree/bindings/input/cros-ec-keyb.txt |   72 +
  Documentation/devicetree/bindings/mfd/cros-ec.txt  |   56 +
  drivers/input/keyboard/Kconfig |   12 +
  drivers/input/keyboard/Makefile|1 +
  drivers/input/keyboard/cros_ec_keyb.c  |  334 +
  drivers/input/keyboard/lpc32xx-keys.c  |   11 +-
  drivers/input/keyboard/omap4-keypad.c  |   16 +-
  drivers/input/keyboard/tca8418_keypad.c|7 +-
  drivers/input/matrix-keymap.c  |   19 +
  drivers/mfd/Kconfig|   28 +
  drivers/mfd/Makefile   |3 +
  drivers/mfd/cros_ec.c  |  189 +++
  drivers/mfd/cros_ec_i2c.c  |  206 +++
  drivers/mfd/cros_ec_spi.c  |  375 ++
  include/linux/input/matrix_keypad.h|   19 +
  include/linux/mfd/cros_ec.h|  170 +++
  include/linux/mfd/cros_ec_commands.h   | 1369

[PATCH v6 0/6] Add ChromeOS Embedded Controller support

[Simon Glass]

The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
line is used to indicate when the EC needs service.

Functions performed by the EC vary by platform, but typically include
battery charging, keyboard scanning and power sequencing.

This series includes support for the EC message protocol, and implements
a matrix keyboard handler for Linux using the protocol. The EC performs
key scanning and passes scan data in response to AP requests. This is
used on the Samsung ARM Chromebook. No driver is available for LPC at
present.

This series can in principle operate on any hardware, but for it to actually
work on the Samsung ARM Chromebook, it needs patches which are currently in
progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.

The driver is device-tree-enabled and a suitable binding is included in
this series. Example device tree nodes are included in the examples,
but no device tree patch for exynos5250-snow is provided at this stage, since
we must wait for the above-mentioned patches to land to avoid errors from
dtc. This can be added with a follow-on patch when that work is complete.

Changes in v6:
- Allow cros_ec to be a module
- Remove 'struct i2c_msg' definition
- Use %ph instead of for loop to output packet trace
- Fix incorrect indentation in cros_ec_keyb_process()
- Remove unnecessary assignment to NULL in probe function

Changes in v5:
- Remove cros_ec allocation functions
- Remove name access functions in cros_ec, using strings instead
- Fix Kconfig help message for MFD_CROS_EC_I2C
- Remove I2C retry logic
- Switch cros_ec_i2c driver to use devm
- Update cros_ec_i2c to work with new cros_ec interface
- Switch cros_ec_spi driver to use devm
- Update cros_ec_spi to work with new cros_ec interface
- Fix {} style nit in cros_ec_keyb_has_ghosting
- Correct key lookup logic which was broken in previous version
- Switch cros_ec_keyb driver to use devm

Changes in v4:
- Fix up trvial logging comments
- Remove messages reporting out of memory
- Add compatible string for cros-ec-keyb
- Remove wake notifier and let drivers use their own handlers instead
- Add 'depends on MFD_CROS_EC' to Kconfig
- Remove use of wake_notifier
- Remove manual code to locate device tree node
- Add resume handler to clear keyboard scan buffer if required

Changes in v3:
- Add stub for matrix_keypad_parse_of_params() when no CONFIG_OF
- Put back full DT range checking in tca8418 driver
- Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
- Remove old_state by using input layer's idev-key
- Move inner loop of cros_ec_keyb_has_ghosting() into its own function and 
simplify
- Add check for not finding the device tree node
- Remove comment about leaking matrix_keypad_build_keymap()
- Use platform_get_drvdata() where possible
- Remove call to input_free_device() after input_unregister_device()

Changes in v2:
- Remove use of __devinit/__devexit
- Remove use of __devinit/__devexit
- Remove use of __devinit/__devexit
- Add new patch to decode matrix-keypad DT binding
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols

Simon Glass (6):
  mfd: Add ChromeOS EC messages header
  mfd: Add ChromeOS EC implementation
  mfd: Add ChromeOS EC I2C driver
  mfd: Add ChromeOS EC SPI driver
  Input: matrix-keymap: Add function to read the new DT binding
  Input: Add ChromeOS EC keyboard driver

 .../devicetree/bindings/input/cros-ec-keyb.txt |   72 +
 Documentation/devicetree/bindings/mfd/cros-ec.txt  |   56 +
 drivers/input/keyboard/Kconfig |   12 +
 drivers/input/keyboard/Makefile|1 +
 drivers/input/keyboard/cros_ec_keyb.c  |  334 +
 drivers/input/keyboard/lpc32xx-keys.c  |   11 +-
 drivers/input/keyboard/omap4-keypad.c  |   16 +-
 drivers/input/keyboard/tca8418_keypad.c|7 +-
 drivers/input/matrix-keymap.c  |   19 +
 drivers/mfd/Kconfig|   28 +
 drivers/mfd/Makefile   |3 +
 drivers/mfd/cros_ec.c  |  189 +++
 drivers/mfd/cros_ec_i2c.c  |  206 +++
 drivers/mfd/cros_ec_spi.c  |  375 ++
 include/linux/input/matrix_keypad.h|   19 +
 include/linux/mfd/cros_ec.h|  170 +++
 include/linux/mfd/cros_ec_commands.h   | 1369 
 17 files changed, 2869 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
 create

[PATCH v6 2/6] mfd: Add ChromeOS EC implementation

[Simon Glass]

This is the base EC implementation, which provides a high level
interface to the EC for use by the rest of the kernel. The actual
communcations is dealt with by a separate protocol driver which
registers itself with this interface.

Interrupts are passed on through a notifier.

A simple message structure is used to pass messages to the
protocol driver.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Che-Liang Chiou clch...@chromium.org
Signed-off-by: Jonathan Kliegman kli...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Olof Johansson ol...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
Changes in v6:
- Allow cros_ec to be a module
- Remove 'struct i2c_msg' definition

Changes in v5:
- Remove cros_ec allocation functions
- Remove name access functions in cros_ec, using strings instead

Changes in v4:
- Fix up trvial logging comments
- Remove messages reporting out of memory
- Add compatible string for cros-ec-keyb
- Remove wake notifier and let drivers use their own handlers instead

Changes in v3: None
Changes in v2:
- Remove use of __devinit/__devexit

 Documentation/devicetree/bindings/mfd/cros-ec.txt |  56 +++
 drivers/mfd/Kconfig   |   8 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/cros_ec.c | 189 ++
 include/linux/mfd/cros_ec.h   | 170 +++
 5 files changed, 424 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
 create mode 100644 drivers/mfd/cros_ec.c
 create mode 100644 include/linux/mfd/cros_ec.h

diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt 
b/Documentation/devicetree/bindings/mfd/cros-ec.txt
new file mode 100644
index 000..e0e59c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -0,0 +1,56 @@
+ChromeOS Embedded Controller
+
+Google's ChromeOS EC is a Cortex-M device which talks to the AP and
+implements various function such as keyboard and battery charging.
+
+The EC can be connect through various means (I2C, SPI, LPC) and the
+compatible string used depends on the inteface. Each connection method has
+its own driver which connects to the top level interface-agnostic EC driver.
+Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
+the top-level driver.
+
+Required properties (I2C):
+- compatible: google,cros-ec-i2c
+- reg: I2C slave address
+
+Required properties (SPI):
+- compatible: google,cros-ec-spi
+- reg: SPI chip select
+
+Required properties (LPC):
+- compatible: google,cros-ec-lpc
+- reg: List of (IO address, size) pairs defining the interface uses
+
+
+Example for I2C:
+
+i2c@12CA {
+   cros-ec@1e {
+   reg = 0x1e;
+   compatible = google,cros-ec-i2c;
+   interrupts = 14 0;
+   interrupt-parent = wakeup_eint;
+   wakeup-source;
+   };
+
+
+Example for SPI:
+
+spi@131b {
+   ec@0 {
+   compatible = google,cros-ec-spi;
+   reg = 0x0;
+   interrupts = 14 0;
+   interrupt-parent = wakeup_eint;
+   wakeup-source;
+   spi-max-frequency = 500;
+   controller-data {
+   cs-gpio = gpf0 3 4 3 0;
+   samsung,spi-cs;
+   samsung,spi-feedback-delay = 2;
+   };
+   };
+};
+
+
+Example for LPC is not supplied as it is not yet implemented.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ff553ba..554dc09 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -21,6 +21,14 @@ config MFD_88PM860X
  select individual components like voltage regulators, RTC and
  battery-charger under the corresponding menus.
 
+config MFD_CROS_EC
+   tristate Support ChromeOS Embedded Controller
+   help
+ If you say Y here you get support for the ChromeOS Embedded
+ Controller (EC) providing keyboard, battery and power services.
+ You also ned to enable the driver for the bus you are using. The
+ protocol for talking to the EC is defined by the bus driver.
+
 config MFD_88PM800
tristate Support Marvell 88PM800
depends on I2C=y  GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8b977f8..f2d8756 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM800)   += 88pm800.o 88pm80x.o
 obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
+obj-$(CONFIG_MFD_CROS_EC)  += cros_ec.o
 
 rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
new file mode 100644
index 000..ac824cc
--- /dev/null

[PATCH v6 6/6] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Use the key-matrix layer to interpret key scan information from the EC
and inject input based on the FDT-supplied key map. This driver registers
itself with the ChromeOS EC driver to perform communications.

The matrix-keypad FDT binding is used with a small addition to control
ghosting.

Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
Changes in v6:
- Fix incorrect indentation in cros_ec_keyb_process()
- Remove unnecessary assignment to NULL in probe function

Changes in v5:
- Fix {} style nit in cros_ec_keyb_has_ghosting
- Correct key lookup logic which was broken in previous version
- Switch cros_ec_keyb driver to use devm

Changes in v4:
- Add 'depends on MFD_CROS_EC' to Kconfig
- Remove use of wake_notifier
- Remove manual code to locate device tree node
- Add resume handler to clear keyboard scan buffer if required

Changes in v3:
- Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
- Remove old_state by using input layer's idev-key
- Move inner loop of cros_ec_keyb_has_ghosting() into its own function and 
simplify
- Add check for not finding the device tree node
- Remove comment about leaking matrix_keypad_build_keymap()
- Use platform_get_drvdata() where possible
- Remove call to input_free_device() after input_unregister_device()

Changes in v2:
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols

 .../devicetree/bindings/input/cros-ec-keyb.txt |  72 +
 drivers/input/keyboard/Kconfig |  12 +
 drivers/input/keyboard/Makefile|   1 +
 drivers/input/keyboard/cros_ec_keyb.c  | 334 +
 4 files changed, 419 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c

diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt 
b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000..0f6355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: google,cros-ec-keyb
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+   compatible = google,cros-ec-keyb;
+   keypad,num-rows = 8;
+   keypad,num-columns = 13;
+   google,needs-ghost-filter;
+   /*
+* Keymap entries take the form of 0xRRCC where
+* RR=Row CC=Column =Key Code
+* The values below are for a US keyboard layout and
+* are taken from the Linux driver. Note that the
+* 102ND key is not used for US keyboards.
+*/
+   linux,keymap = 
+   /* CAPSLCK F1 B  F10 */
+   0x0001003a 0x0002003b 0x00030030 0x00040044
+   /* N   =  R_ALT  ESC */
+   0x00060031 0x0008000d 0x000a0064 0x01010001
+   /* F4  G  F7 H   */
+   0x0102003e 0x01030022 0x01040041 0x01060023
+   /* '   F9 BKSPACEL_CTRL  */
+   0x01080028 0x01090043 0x010b000e 0x021d
+   /* TAB F3 T  F6  */
+   0x0201000f 0x0202003d 0x02030014 0x02040040
+   /* ]   Y  102ND  [   */
+   0x0205001b 0x02060015 0x02070056 0x0208001a
+   /* F8  GRAVE  F2 5   */
+   0x02090042 0x03010029 0x0302003c 0x03030006
+   /* F5  6  -  \   */
+   0x0304003f 0x03060007 0x0308000c 0x030b002b
+   /* R_CTRL  A  D  F   */
+   0x0461 0x0401001e 0x04020020 0x04030021
+   /* S   K  J  ;   */
+   0x0404001f 0x04050025 0x04060024 0x04080027
+   /* L   ENTER  Z  C   */
+   0x04090026 0x040b001c 0x0501002c 0x0502002e
+   /* V   X  ,  M   */
+   0x0503002f 0x0504002d 0x05050033 0x05060032
+   /* L_SHIFT /  .  SPACE   */
+   0x0507002a 0x05080035 0x05090034 0x050B0039
+   /* 1   3  4  2

[PATCH v5 0/6] Add ChromeOS Embedded Controller support

[Simon Glass]

The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
line is used to indicate when the EC needs service.

Functions performed by the EC vary by platform, but typically include
battery charging, keyboard scanning and power sequencing.

This series includes support for the EC message protocol, and implements
a matrix keyboard handler for Linux using the protocol. The EC performs
key scanning and passes scan data in response to AP requests. This is
used on the Samsung ARM Chromebook. No driver is available for LPC at
present.

This series can in principle operate on any hardware, but for it to actually
work on the Samsung ARM Chromebook, it needs patches which are currently in
progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.

The driver is device-tree-enabled and a suitable binding is included in
this series. Example device tree nodes are included in the examples,
but no device tree patch for exynos5250-snow is provided at this stage, since
we must wait for the above-mentioned patches to land to avoid errors from
dtc. This can be added with a follow-on patch when that work is complete.

Changes in v5:
- Remove cros_ec allocation functions
- Remove name access functions in cros_ec, using strings instead
- Fix Kconfig help message for MFD_CROS_EC_I2C
- Remove I2C retry logic
- Switch cros_ec_i2c driver to use devm
- Update cros_ec_i2c to work with new cros_ec interface
- Switch cros_ec_spi driver to use devm
- Update cros_ec_spi to work with new cros_ec interface
- Fix {} style nit in cros_ec_keyb_has_ghosting
- Correct key lookup logic which was broken in previous version
- Switch cros_ec_keyb driver to use devm

Changes in v4:
- Fix up trvial logging comments
- Remove messages reporting out of memory
- Add compatible string for cros-ec-keyb
- Remove wake notifier and let drivers use their own handlers instead
- Add 'depends on MFD_CROS_EC' to Kconfig
- Remove use of wake_notifier
- Remove manual code to locate device tree node
- Add resume handler to clear keyboard scan buffer if required

Changes in v3:
- Add stub for matrix_keypad_parse_of_params() when no CONFIG_OF
- Put back full DT range checking in tca8418 driver
- Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
- Remove old_state by using input layer's idev-key
- Move inner loop of cros_ec_keyb_has_ghosting() into its own function and 
simplify
- Add check for not finding the device tree node
- Remove comment about leaking matrix_keypad_build_keymap()
- Use platform_get_drvdata() where possible
- Remove call to input_free_device() after input_unregister_device()

Changes in v2:
- Remove use of __devinit/__devexit
- Remove use of __devinit/__devexit
- Remove use of __devinit/__devexit
- Add new patch to decode matrix-keypad DT binding
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols

Simon Glass (6):
  mfd: Add ChromeOS EC messages header
  mfd: Add ChromeOS EC implementation
  mfd: Add ChromeOS EC I2C driver
  mfd: Add ChromeOS EC SPI driver
  Input: matrix-keymap: Add function to read the new DT binding
  Input: Add ChromeOS EC keyboard driver

 .../devicetree/bindings/input/cros-ec-keyb.txt |   72 +
 Documentation/devicetree/bindings/mfd/cros-ec.txt  |   56 +
 drivers/input/keyboard/Kconfig |   12 +
 drivers/input/keyboard/Makefile|1 +
 drivers/input/keyboard/cros_ec_keyb.c  |  334 +
 drivers/input/keyboard/lpc32xx-keys.c  |   11 +-
 drivers/input/keyboard/omap4-keypad.c  |   16 +-
 drivers/input/keyboard/tca8418_keypad.c|7 +-
 drivers/input/matrix-keymap.c  |   19 +
 drivers/mfd/Kconfig|   28 +
 drivers/mfd/Makefile   |3 +
 drivers/mfd/cros_ec.c  |  189 +++
 drivers/mfd/cros_ec_i2c.c  |  210 +++
 drivers/mfd/cros_ec_spi.c  |  375 ++
 include/linux/input/matrix_keypad.h|   19 +
 include/linux/mfd/cros_ec.h|  172 +++
 include/linux/mfd/cros_ec_commands.h   | 1369 
 17 files changed, 2875 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
 create mode 100644 drivers/mfd/cros_ec.c
 create mode 100644 drivers/mfd/cros_ec_i2c.c
 create mode 100644 drivers/mfd/cros_ec_spi.c
 create mode 100644 include/linux/mfd/cros_ec.h
 create mode 100644 include/linux/mfd/cros_ec_commands.h

-- 
1.8.1.3

[PATCH v5 2/6] mfd: Add ChromeOS EC implementation

[Simon Glass]

This is the base EC implementation, which provides a high level
interface to the EC for use by the rest of the kernel. The actual
communcations is dealt with by a separate protocol driver which
registers itself with this interface.

Interrupts are passed on through a notifier.

A simple message structure is used to pass messages to the
protocol driver.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Che-Liang Chiou clch...@chromium.org
Signed-off-by: Jonathan Kliegman kli...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Olof Johansson ol...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
Changes in v5:
- Remove cros_ec allocation functions
- Remove name access functions in cros_ec, using strings instead

Changes in v4:
- Fix up trvial logging comments
- Remove messages reporting out of memory
- Add compatible string for cros-ec-keyb
- Remove wake notifier and let drivers use their own handlers instead

Changes in v3: None
Changes in v2:
- Remove use of __devinit/__devexit

 Documentation/devicetree/bindings/mfd/cros-ec.txt |  56 +++
 drivers/mfd/Kconfig   |   8 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/cros_ec.c | 189 ++
 include/linux/mfd/cros_ec.h   | 172 
 5 files changed, 426 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
 create mode 100644 drivers/mfd/cros_ec.c
 create mode 100644 include/linux/mfd/cros_ec.h

diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt 
b/Documentation/devicetree/bindings/mfd/cros-ec.txt
new file mode 100644
index 000..e0e59c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -0,0 +1,56 @@
+ChromeOS Embedded Controller
+
+Google's ChromeOS EC is a Cortex-M device which talks to the AP and
+implements various function such as keyboard and battery charging.
+
+The EC can be connect through various means (I2C, SPI, LPC) and the
+compatible string used depends on the inteface. Each connection method has
+its own driver which connects to the top level interface-agnostic EC driver.
+Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
+the top-level driver.
+
+Required properties (I2C):
+- compatible: google,cros-ec-i2c
+- reg: I2C slave address
+
+Required properties (SPI):
+- compatible: google,cros-ec-spi
+- reg: SPI chip select
+
+Required properties (LPC):
+- compatible: google,cros-ec-lpc
+- reg: List of (IO address, size) pairs defining the interface uses
+
+
+Example for I2C:
+
+i2c@12CA {
+   cros-ec@1e {
+   reg = 0x1e;
+   compatible = google,cros-ec-i2c;
+   interrupts = 14 0;
+   interrupt-parent = wakeup_eint;
+   wakeup-source;
+   };
+
+
+Example for SPI:
+
+spi@131b {
+   ec@0 {
+   compatible = google,cros-ec-spi;
+   reg = 0x0;
+   interrupts = 14 0;
+   interrupt-parent = wakeup_eint;
+   wakeup-source;
+   spi-max-frequency = 500;
+   controller-data {
+   cs-gpio = gpf0 3 4 3 0;
+   samsung,spi-cs;
+   samsung,spi-feedback-delay = 2;
+   };
+   };
+};
+
+
+Example for LPC is not supplied as it is not yet implemented.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ff553ba..fcb0c00 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -21,6 +21,14 @@ config MFD_88PM860X
  select individual components like voltage regulators, RTC and
  battery-charger under the corresponding menus.
 
+config MFD_CROS_EC
+   bool Support ChromeOS Embedded Controller
+   help
+ If you say Y here you get support for the ChromeOS Embedded
+ Controller (EC) providing keyboard, battery and power services.
+ You also ned to enable the driver for the bus you are using. The
+ protocol for talking to the EC is defined by the bus driver.
+
 config MFD_88PM800
tristate Support Marvell 88PM800
depends on I2C=y  GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8b977f8..f2d8756 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM800)   += 88pm800.o 88pm80x.o
 obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
+obj-$(CONFIG_MFD_CROS_EC)  += cros_ec.o
 
 rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
new file mode 100644
index 000..ac824cc
--- /dev/null
+++ b/drivers/mfd/cros_ec.c
@@ -0,0 +1,189 @@
+/*
+ * ChromeOS EC multi-function device

[PATCH v5 6/6] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Use the key-matrix layer to interpret key scan information from the EC
and inject input based on the FDT-supplied key map. This driver registers
itself with the ChromeOS EC driver to perform communications.

The matrix-keypad FDT binding is used with a small addition to control
ghosting.

Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
Changes in v5:
- Fix {} style nit in cros_ec_keyb_has_ghosting
- Correct key lookup logic which was broken in previous version
- Switch cros_ec_keyb driver to use devm

Changes in v4:
- Add 'depends on MFD_CROS_EC' to Kconfig
- Remove use of wake_notifier
- Remove manual code to locate device tree node
- Add resume handler to clear keyboard scan buffer if required

Changes in v3:
- Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
- Remove old_state by using input layer's idev-key
- Move inner loop of cros_ec_keyb_has_ghosting() into its own function and 
simplify
- Add check for not finding the device tree node
- Remove comment about leaking matrix_keypad_build_keymap()
- Use platform_get_drvdata() where possible
- Remove call to input_free_device() after input_unregister_device()

Changes in v2:
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols

 .../devicetree/bindings/input/cros-ec-keyb.txt |  72 +
 drivers/input/keyboard/Kconfig |  12 +
 drivers/input/keyboard/Makefile|   1 +
 drivers/input/keyboard/cros_ec_keyb.c  | 334 +
 4 files changed, 419 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c

diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt 
b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000..0f6355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: google,cros-ec-keyb
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+   compatible = google,cros-ec-keyb;
+   keypad,num-rows = 8;
+   keypad,num-columns = 13;
+   google,needs-ghost-filter;
+   /*
+* Keymap entries take the form of 0xRRCC where
+* RR=Row CC=Column =Key Code
+* The values below are for a US keyboard layout and
+* are taken from the Linux driver. Note that the
+* 102ND key is not used for US keyboards.
+*/
+   linux,keymap = 
+   /* CAPSLCK F1 B  F10 */
+   0x0001003a 0x0002003b 0x00030030 0x00040044
+   /* N   =  R_ALT  ESC */
+   0x00060031 0x0008000d 0x000a0064 0x01010001
+   /* F4  G  F7 H   */
+   0x0102003e 0x01030022 0x01040041 0x01060023
+   /* '   F9 BKSPACEL_CTRL  */
+   0x01080028 0x01090043 0x010b000e 0x021d
+   /* TAB F3 T  F6  */
+   0x0201000f 0x0202003d 0x02030014 0x02040040
+   /* ]   Y  102ND  [   */
+   0x0205001b 0x02060015 0x02070056 0x0208001a
+   /* F8  GRAVE  F2 5   */
+   0x02090042 0x03010029 0x0302003c 0x03030006
+   /* F5  6  -  \   */
+   0x0304003f 0x03060007 0x0308000c 0x030b002b
+   /* R_CTRL  A  D  F   */
+   0x0461 0x0401001e 0x04020020 0x04030021
+   /* S   K  J  ;   */
+   0x0404001f 0x04050025 0x04060024 0x04080027
+   /* L   ENTER  Z  C   */
+   0x04090026 0x040b001c 0x0501002c 0x0502002e
+   /* V   X  ,  M   */
+   0x0503002f 0x0504002d 0x05050033 0x05060032
+   /* L_SHIFT /  .  SPACE   */
+   0x0507002a 0x05080035 0x05090034 0x050B0039
+   /* 1   3  4  2   */
+   0x06010002 0x06020004 0x06030005 0x06040003
+   /* 8   7  0  9

Re: [PATCH v4 6/6] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Hi,

On Tue, Feb 19, 2013 at 12:36 AM, li guang lig.f...@cn.fujitsu.com wrote:
 在 2013-02-15五的 20:16 -0800，Simon Glass写道：
 Use the key-matrix layer to interpret key scan information from the EC
 and inject input based on the FDT-supplied key map. This driver registers
 itself with the ChromeOS EC driver to perform communications.

 [snip ...]
 +/*
 + * Returns true when there is at least one combination of pressed keys that
 + * results in ghosting.
 + */
 +static bool cros_ec_keyb_has_ghosting(struct cros_ec_keyb *ckdev, uint8_t 
 *buf)
 +{
 + int row;
 +
 + /*
 +  * Ghosting happens if for any pressed key X there are other keys
 +  * pressed both in the same row and column of X as, for instance,
 +  * in the following diagram:
 +  *
 +  * . . Y . g .
 +  * . . . . . .
 +  * . . . . . .
 +  * . . X . Z .
 +  *
 +  * In this case only X, Y, and Z are pressed, but g appears to be
 +  * pressed too (see Wikipedia).
 +  *
 +  * We can detect ghosting in a single pass (*) over the keyboard state
 +  * by maintaining two arrays.  pressed_in_row counts how many pressed
 +  * keys we have found in a row.  row_has_teeth is true if any of the
 +  * pressed keys for this row has other pressed keys in its column.  If
 +  * at any point of the scan we find that a row has multiple pressed
 +  * keys, and at least one of them is at the intersection with a column
 +  * with multiple pressed keys, we're sure there is ghosting.
 +  * Conversely, if there is ghosting, we will detect such situation for
 +  * at least one key during the pass.
 +  *
 +  * (*) This looks linear in the number of keys, but it's not.  We can
 +  * cheat because the number of rows is small.
 +  */
 + for (row = 0; row  ckdev-rows; row++) {
 + if (cros_ec_keyb_row_has_ghosting(ckdev, buf, row))
 + return true;
 + }
 +
 + return false;
 +}

 are you sure your EC's firmware did not do ghost-key detection?
 or, did you test ghost-key with/without your own ghost-key detection?
 as far as I know, ghost-key should be take care either by keyboard
 designer or firmware.


Yes, the matrix scans are sent from the EC in a raw form - in fact the
EC on snow does not even know the keycode map. The EC does handle
debouncing though. The idea is to reduce code/complexity in the EC
where we are space-constrained.

[snip]

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v4 6/6] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Hi Dmitry,

On Sat, Feb 16, 2013 at 12:49 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 Hi Simon,

 On Fri, Feb 15, 2013 at 08:16:12PM -0800, Simon Glass wrote:
 + for (row = 0; row  ckdev-rows; row++) {
 + if (cros_ec_keyb_row_has_ghosting(ckdev, buf, row))
 + return true;
 + }

 No need for curly braces here. I would not care if not for below.

OK I dont't think I even knew about that rule. Actually, what is that rule?


 +
 + return 0;
 +
 +fail_register:
 + kfree(idev-keycode);

 Sorry I did not notice this before, but idev-keycode is devm-managed,
 so you either need to use devm_kfree() or just remove call to kfree()
 and let it clean up automatically (which will happen if binding fails or
 upon removal).

 BTW, maybe you should move the whole driver to devm_*? We have
 devm_kzalloc() for ckdev and you can use devm_input_allocate_device().
 Then you can get rid of entire erro handling path and completely remove
 the remove() method as well.

Yes I was thinking about that - might as well do it now.


 +fail_matrix:
 + input_free_device(idev);
 +fail_alloc_dev:
 + kfree(ckdev);
 + return err;
 +}
 +

 Thanks.

 --
 Dmitry

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [v3 0/6] ARM: tegra: convert device tree files to use CLK defines

[Simon Glass]

Hi Hiroshi,

On Fri, Feb 15, 2013 at 12:43 AM, Hiroshi Doyu hd...@nvidia.com wrote:
 Hi,

 With new dtc+cpp feature, we could get rid of magic numbers in dts*
 files. This patch replaces CLK IDs.

 We also plan to share those DT header files with kernel source
 later[1].

 This series depends on:
   [PATCH 0/9] ARM: tegra: use new dtc+cpp feature
   
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/149613.html

 [5/6] and [6/6] depend on:
   [PATCH v6 00/10] Tegra114 clockframework
   
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/148895.html

 v2:
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/149816.html

 v1:
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/149672.html

 [1] 
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/149804.html


 Hiroshi Doyu (6):
   ARM: tegra20: create a DT header defining CLK IDs
   ARM: tegra20: convert device tree files to use CLK defines
   ARM: tegra30: create a DT header defining CLK IDs
   ARM: tegra30: convert device tree files to use CLK defines
   ARM: tegra114: create a DT header defining CLK IDs
   ARM: tegra114: convert device tree files to use CLK defines

I wonder what sort of error message do you get when you make a mistake
in the .dts or one of the .dtsi includes? If cpp is handling the
including, does dtc just see a single file, in which case are the line
numbers printed with each error not much use? Or does dtc handle the
#line directives?

Just curious...

Regards,
Simon


  .../bindings/clock/nvidia,tegra114-car.txt |  261 +--
  .../bindings/clock/nvidia,tegra20-car.txt  |  150 +--
  .../bindings/clock/nvidia,tegra30-car.txt  |  207 +--
  arch/arm/boot/dts/tegra114-car.h   |  272 
 
  arch/arm/boot/dts/tegra114.dtsip   |   13 +-
  arch/arm/boot/dts/tegra20-car.h|  158 
  arch/arm/boot/dts/tegra20-paz00.dtsp   |2 +-
  arch/arm/boot/dts/tegra20.dtsip|   85 +++---
  arch/arm/boot/dts/tegra30-car.h|  218 
  arch/arm/boot/dts/tegra30.dtsip|   87 +++
  10 files changed, 746 insertions(+), 707 deletions(-)
  create mode 100644 arch/arm/boot/dts/tegra114-car.h
  create mode 100644 arch/arm/boot/dts/tegra20-car.h
  create mode 100644 arch/arm/boot/dts/tegra30-car.h

 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-tegra in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 5/8] libfdt: Add function to find regions in an FDT

[Simon Glass]

Hi David,

On Sun, Feb 10, 2013 at 6:47 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
 On Mon, Jan 21, 2013 at 12:59:19PM -0800, Simon Glass wrote:
 Given a set of nodes and properties, find the regions of the device tree
 which describe those parts.

 A test is provided which builds a tree while tracking where the regions
 should be, then calls fdt_find_regions() to make sure that it agrees.

 Further tests will come as part of fdtgrep.

 Ok, for starters I don't want to include this before the next dtc
 release.  It's a pretty substantial addition.

 Second, fdt_wip is definitely the wrong place for this.  fdt_wip.c is
 for the Write-In-Place code (i.e. functions which alter the tree
 contents, but don't need to move any existing data around).  AFAICT
 this function only reads the tree, which would put it in fdt_ro.c.
 However, it's such a big addition - and adds several new state
 structures, I think it should go in an entirely new source file for
 it.  That way people who don't use this piece of the library won't get
 it included, even if they don't have a compiler which does function
 sections.

OK I misunderstood the name of that file - I will add a new file.


 Third, I'm having a bit of trouble wrapping my head around exactly
 what the search function does, and how the various flags and pieces
 interact.  A block comment with a general overview would be nice.

 More specific comments below:


 Signed-off-by: Simon Glass s...@chromium.org
 ---
  libfdt/fdt_wip.c |  311 
  libfdt/libfdt.h  |  142 ++
  tests/.gitignore |1 +
  tests/Makefile.tests |3 +-
  tests/region_tree.c  |  324 
 ++
  tests/run_tests.sh   |5 +
  6 files changed, 785 insertions(+), 1 deletions(-)
  create mode 100644 tests/region_tree.c

 diff --git a/libfdt/fdt_wip.c b/libfdt/fdt_wip.c
 index c5bbb68..ff0f940 100644
 --- a/libfdt/fdt_wip.c
 +++ b/libfdt/fdt_wip.c
 @@ -116,3 +116,314 @@ int fdt_nop_node(void *fdt, int nodeoffset)
   endoffset - nodeoffset);
   return 0;
  }
 +
 +/* Maximum depth that we can grep */
 +#define FDT_MAX_DEPTH32
 +
 +/* Decribes what we want to include from the current tag */
 +enum want_t {
 + WANT_NOTHING,
 + WANT_NODES_ONLY,
 + WANT_NODES_AND_PROPS,
 +};
 +
 +/* Keeps track of the state at parent nodes */
 +struct fdt_subnode_stack {
 + int offset; /* Offset of node */
 + enum want_t want;   /* The 'want' value here */
 + int included;   /* 1 if we included this node, 0 if not */

 What's the distinction between 'included' and 'want' and how do they
 interact?

I will add a big comment for that.


 +};
 +
 +/* The state of our finding algortihm */
 +struct find_reg {
 + struct fdt_subnode_stack stack[FDT_MAX_DEPTH];  /* node stack */
 + struct fdt_region *region;  /* Contains list of regions found */
 + int count;  /* Numnber of regions found */
 + const void *fdt;/* FDT blob */
 + int max_regions;/* Maximum regions to find */
 + int can_merge;  /* 1 if we can merge with previous region */
 +};
 +
 +/**
 + * fdt_add_region() - Add a new region to our list
 + *
 + * The region is added if there is space, but in any case we increment the
 + * count. If permitted, and the new region overlaps the last one, we merge
 + * them.
 + *
 + * @info: State information
 + * @offset: Start offset of region
 + * @size: Size of region
 + */
 +static void fdt_add_region(struct find_reg *info, int offset, int size)
 +{
 + struct fdt_region *reg = info-region[info-count - 1];
 +
 + if (info-can_merge  info-count 
 + info-count  info-max_regions 

 Shouldn't this be = for the merge case?

Yes, thanks.


 + offset = reg-offset + reg-size) {
 + reg-size = offset + size - reg-offset;
 + } else if (info-count  info-max_regions) {
 + reg++;
 + reg-offset = offset;
 + reg-size = size;
 + info-count++;
 + }
 +}
 +
 +/**
 + * fdt_include_supernodes() - Include supernodes required by this node
 + *
 + * When we decided to include a node or property which is not at the top
 + * level, this function forces the inclusion of higher level nodes. For
 + * example, given this tree:
 + *
 + * / {
 + * testing {
 + * }
 + * }
 + *
 + * If we decide to include testing then we need the root node to have a 
 valid
 + * tree. This function adds those regions.
 + *
 + * @info: State information
 + * @depth: Current stack depth
 + */
 +static void fdt_include_supernodes(struct find_reg *info, int depth)
 +{
 + int base = fdt_off_dt_struct(info-fdt);
 + int start, stop_at;
 + int i;
 +
 + /*
 +  * Work down the stack looking for supernodes that we didn't include.
 +  * The algortihm here

[PATCH v2 0/3] Introduce fdtgrep for subsetting and hashing FDTs

[Simon Glass]

This series adds two new functions, fdt_first_region() and
fdt_next_regions() which map FDT parts such as nodes and properties to
their regions in the FDT binary. The function is then used to implement
a grep utility for FDTs.

The core core is quite simple and small, but it grew a little due
to the need to make it iterative (first/next/next). Also this series adds
tests and a grep utility, so quite a bit of code is built on it.

The use for this feature is twofold. Firstly it provides a convenient
way of performing a structure-aware grep of the tree. For example it is
possible to grep for a node and get all the properties associated with
that node. Trees can be subsetted easily, by specifying the nodes that
are required, and then writing out the regions returned by this function.
This is useful for small resource-constrained systems, such as boot
loaders, which want to use an FDT but do not need to know about all of
it. The full FDT can be grepped to pull out the few things that are
needed - this can be automatic and does not require the FDT source code.

This first use makes it easy to implement an FDT grep. Options are
provided to search for matching nodes (by name or compatible string),
properties and also for any of the above. It is possible to search for
non-matches also (useful for excluding a particular property from the
FDT, for example). The output is like fdtdump, but only with the regions
selected by the grep. Options are also provided to print the string table,
memory reservation table, etc. The fdtgrep utility can output valid
source, which can be used by dtc, but it can also directly output a new
.dtb binary.

Secondly it makes it easy to hash parts of the tree and detect changes.
The intent is to get a list of regions which will be invariant provided
those parts are invariant. For example, if you request a list of regions
for all nodes but exclude the property data, then you will get the
same region contents regardless of any change to data properties.
An assumption is made here that the tree ordering remains the same.

This second use is the subject of a recent series sent to the U-Boot
mailing list, to enhance FIT images to support verified boot. Briefly,
this works by signing configurations (consisting of particular kernel
and FDT combinations) so that the boot loader can verify that these
combinations are valid and permitted. Since a FIT image is in fact an
FDT, we need to be able to hash particular regions of the FDT for the
signing and verification process. This is done by using the region functions
to select the data that needs to be hashed for a particular configuration.

The fdtgrep utility could be used to replace all of the functions of
fdtdump. However fdtdump is intended as a separate, simple way of
dumping the tree (for verifying against dtc output for example). So
fdtdump remains a separate program and this series leaves it alone.

Note: a somewhat unfortunately feature of this implementation is that
a state structure needs to be kept around between calls of
fdt_next_region(). This is declared in libfdt.h but really should be
opaque.

Changes in v2:
- Move region code to separate fdt_region.c file
- Fix info-count = info-max_regions in fdt_add_region() merge case
- Add new FDT_ERR_TOODEEP error type and use it
- Change returned error from BADLAYOUT to BADSTRUCTURE
- Return FDT_ERR_BADLAYOUT error if strings block is before structure block
- Add note that changes in node/property order can cause false hash misses
- Add more comments about the -1 return value from h_include
- Drop FDT_IS_COMPAT and pass node offset to h_include function
- Drop stale comment about names / wildcards
- Move to a model with fdt_first_region()/fdt_next_region()
- Add long comment explaining theory of operation
- Add local fdt_find_regions() function since libfdt no longer has it
- Drop patch to replace fdtdump

Simon Glass (3):
  libfdt: Add function to find regions in an FDT
  Add fdtgrep to grep and subset FDTs
  RFC: Check offset in fdt_string()

 .gitignore |   1 +
 Makefile   |   4 +
 Makefile.utils |   7 +
 fdtgrep.c  | 838 +
 libfdt/Makefile.libfdt |   3 +-
 libfdt/fdt_region.c| 452 ++
 libfdt/fdt_ro.c|   2 +
 libfdt/libfdt.h| 213 -
 tests/.gitignore   |   1 +
 tests/Makefile.tests   |   3 +-
 tests/grep.dts |  23 ++
 tests/region_tree.c| 336 
 tests/run_tests.sh | 353 -
 tests/tests.sh |   1 +
 14 files changed, 2233 insertions(+), 4 deletions(-)
 create mode 100644 fdtgrep.c
 create mode 100644 libfdt/fdt_region.c
 create mode 100644 tests/grep.dts
 create mode 100644 tests/region_tree.c

-- 
1.8.1.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v2 2/3] Add fdtgrep to grep and subset FDTs

[Simon Glass]

fdtgrep operates like a grep for device trees, working on binary .dtb
files.

fdtgrep can find nodes by name or compatible string. It can find properties
by name. Using a list of of nodes/properties/compatible strings to match,
fdtgrep creates either .dts text output containing just those matches, or
.dtb output. In the .dtb case, the output is a valid FDT which only includes
the selected nodes/properties. This is useful in resource-constrained systems
where a full FDT is too large to fit in available memory (e.g. U-Boot SPL).

fdtgrep also supports producing raw binary output, without the normal FDT
headers. This can be useful for hashing part of an FDT and making sure that
that part does not change, even if other parts do. This makes it possible to
detect an important change, while ignoring a change that is of no interest.

At its simplest fdtgrep can be used as follows;

   fdtgrep /holiday tests/grep.dtb

and it produces just that node (with a skeleton to hold it):

/ {
holiday {
compatible = ixtapa, mexico;
weather = sunny;
status = okay;
};
};

The binary form of this is:

   fdtgrep -n /holiday -O dtb tests/grep.dtb

which produces a valid DTB file with just the above nodes.

Various options are provided to search for properties, to ensure that
nodes/properties are not present, and to search for nodes by compatible
string.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Add local fdt_find_regions() function since libfdt no longer has it

 .gitignore |   1 +
 Makefile   |   4 +
 Makefile.utils |   7 +
 fdtgrep.c  | 838 +
 tests/grep.dts |  23 ++
 tests/run_tests.sh | 348 +-
 tests/tests.sh |   1 +
 7 files changed, 1221 insertions(+), 1 deletion(-)
 create mode 100644 fdtgrep.c
 create mode 100644 tests/grep.dts

diff --git a/.gitignore b/.gitignore
index 545b899..9d3a550 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@ lex.yy.c
 /convert-dtsv0
 /version_gen.h
 /fdtget
+/fdtgrep
 /fdtput
 /patches
 /.pc
diff --git a/Makefile b/Makefile
index 1169e6c..96e0488 100644
--- a/Makefile
+++ b/Makefile
@@ -112,6 +112,7 @@ BIN += dtc
 BIN += fdtdump
 BIN += fdtget
 BIN += fdtput
+BIN += fdtgrep
 
 SCRIPTS = dtdiff
 
@@ -124,6 +125,7 @@ ifneq ($(DEPTARGETS),)
 -include $(FDTDUMP_OBJS:%.o=%.d)
 -include $(FDTGET_OBJS:%.o=%.d)
 -include $(FDTPUT_OBJS:%.o=%.d)
+-include $(FDTGREP_OBJS:%.o=%.d)
 endif
 
 
@@ -188,6 +190,7 @@ fdtget: $(FDTGET_OBJS) $(LIBFDT_archive)
 
 fdtput:$(FDTPUT_OBJS) $(LIBFDT_archive)
 
+fdtgrep:   $(FDTGREP_OBJS) $(LIBFDT_archive)
 
 #
 # Testsuite rules
@@ -198,6 +201,7 @@ TESTS_BIN += dtc
 TESTS_BIN += convert-dtsv0
 TESTS_BIN += fdtput
 TESTS_BIN += fdtget
+TESTS_BIN += fdtgrep
 
 include tests/Makefile.tests
 
diff --git a/Makefile.utils b/Makefile.utils
index 48ece49..f2a7001 100644
--- a/Makefile.utils
+++ b/Makefile.utils
@@ -22,3 +22,10 @@ FDTPUT_SRCS = \
util.c
 
 FDTPUT_OBJS = $(FDTPUT_SRCS:%.c=%.o)
+
+
+FDTGREP_SRCS = \
+   fdtgrep.c \
+   util.c
+
+FDTGREP_OBJS = $(FDTGREP_SRCS:%.c=%.o)
diff --git a/fdtgrep.c b/fdtgrep.c
new file mode 100644
index 000..91f8a6f
--- /dev/null
+++ b/fdtgrep.c
@@ -0,0 +1,838 @@
+/*
+ * Copyright (c) 2013, Google Inc.
+ *
+ * Perform a grep of an FDT either displaying the source subset or producing
+ * a new .dtb subset which can be used as required.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include assert.h
+#include ctype.h
+#include getopt.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+
+#include libfdt.h
+#include libfdt_internal.h
+#include util.h
+
+/* Define DEBUG to get some debugging output on stderr */
+#ifdef DEBUG
+#define debug(a, b...) fprintf(stderr, a, ## b)
+#else
+#define debug(a, b...)
+#endif
+
+/* A linked list of values we are grepping for */
+struct value_node {
+   int type;   /* Types this value matches (FDT_IS... mask) */
+   int include;/* 1 to include matches, 0 to exclude */
+   const char *string; /* String to match */
+   struct value_node *next;/* Pointer to next node, or NULL */
+};
+
+/* Output formats we support */
+enum output_t {
+   OUT_DTS

[PATCH v2 1/3] libfdt: Add function to find regions in an FDT

[Simon Glass]

Given a set of nodes and properties, find the regions of the device tree
which describe those parts.

A test is provided which builds a tree while tracking where the regions
should be, then calls fdt_first/next_region() to make sure that it agrees.

Further tests will come as part of fdtgrep.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Move region code to separate fdt_region.c file
- Fix info-count = info-max_regions in fdt_add_region() merge case
- Add new FDT_ERR_TOODEEP error type and use it
- Change returned error from BADLAYOUT to BADSTRUCTURE
- Return FDT_ERR_BADLAYOUT error if strings block is before structure block
- Add note that changes in node/property order can cause false hash misses
- Add more comments about the -1 return value from h_include
- Drop FDT_IS_COMPAT and pass node offset to h_include function
- Drop stale comment about names / wildcards
- Move to a model with fdt_first_region()/fdt_next_region()
- Add long comment explaining theory of operation

 libfdt/Makefile.libfdt |   3 +-
 libfdt/fdt_region.c| 452 +
 libfdt/libfdt.h| 213 ++-
 tests/.gitignore   |   1 +
 tests/Makefile.tests   |   3 +-
 tests/region_tree.c| 336 
 tests/run_tests.sh |   5 +
 7 files changed, 1010 insertions(+), 3 deletions(-)
 create mode 100644 libfdt/fdt_region.c
 create mode 100644 tests/region_tree.c

diff --git a/libfdt/Makefile.libfdt b/libfdt/Makefile.libfdt
index 91126c0..84769a4 100644
--- a/libfdt/Makefile.libfdt
+++ b/libfdt/Makefile.libfdt
@@ -6,5 +6,6 @@
 LIBFDT_soname = libfdt.$(SHAREDLIB_EXT).1
 LIBFDT_INCLUDES = fdt.h libfdt.h libfdt_env.h
 LIBFDT_VERSION = version.lds
-LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c 
fdt_empty_tree.c
+LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_region.c
+LIBFDT_SRCS += fdt_rw.c fdt_strerror.c fdt_empty_tree.c
 LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
diff --git a/libfdt/fdt_region.c b/libfdt/fdt_region.c
new file mode 100644
index 000..a830526
--- /dev/null
+++ b/libfdt/fdt_region.c
@@ -0,0 +1,452 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2013 Google, Inc
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ * 2. Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
+ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
+ * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include libfdt_env.h
+
+#include fdt.h
+#include libfdt.h
+
+#include libfdt_internal.h
+
+/**
+ * fdt_add_region() - Add a new region to our list
+ *
+ * The region is added if there is space, but in any case we increment the
+ * count. If permitted, and the new region overlaps the last one, we merge
+ * them.
+ *
+ * @info: State information
+ * @offset: Start offset

Re: [PATCH v2 6/6] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Hi Dmitry,

On Thu, Feb 14, 2013 at 9:31 AM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 On Wed, Feb 13, 2013 at 10:45:07PM -0800, Simon Glass wrote:
 
  +config KEYBOARD_CROS_EC
  + tristate ChromeOS EC keyboard
  + select INPUT_MATRIXKMAP
  + select MFD_CROS_EC
 
  Is this select safe? I.e. does MFD_CROS_EC depend on anything else?

 I'll remove it, since it isn't required, and it's true that it does
 need other things.

 Instead of droppign the dependency completely I think it should depens
 on MFD_CROS_EC

OK, done.


  +
  +static void cros_ec_keyb_close(struct input_dev *dev)
  +{
  + struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
  +
  + blocking_notifier_chain_unregister(ckdev-ec-event_notifier,
  +ckdev-notifier);
  + blocking_notifier_chain_unregister(ckdev-ec-wake_notifier,
  +ckdev-wake_notifier);
 
  Why is this done via a notifier instead of regular resume method?

 Because we only call the notifer in resume when we were not waking on
 a keyboard event. We use it to flush the keyboard. It was a late
 change so there might be a better way, but this driver does not have a
 resume handler.

 Right and the question is why does not it have resume handler and why
 you inventing your own resume infrastructure instead of using the
 standard one.

I will fix that.


  +
  +static int cros_ec_keyb_probe(struct platform_device *pdev)
  +{
  + struct cros_ec_device *ec = dev_get_drvdata(pdev-dev.parent);
  + struct device *dev = ec-dev;
  + struct cros_ec_keyb *ckdev = NULL;
  + struct input_dev *idev = NULL;
  + struct device_node *np;
  + int err;
  +
  + np = of_find_matching_node(NULL, cros_ec_kbc_of_match);
 
  And if we don't find it?

 Added error checking.

 
  +
  + ckdev = kzalloc(sizeof(*ckdev), GFP_KERNEL);
  + if (!ckdev) {
  + dev_err(dev, cannot allocate memory for ckdev\n);
  + return -ENOMEM;
  + }
  + pdev-dev.of_node = np;
 
  Huh? I'd expect the platform device be fully set up (including DT data)
  before the driver is called.

 This is a child of the mfd driver cros_ec, so I don't think that
 works. Or maybe I'm just not sure how to plumb it in so it is
 automatic. Or maybe I just need to add the id to the device info
 below?

 Who creates this device? Whoever does this should set up the
 pdev-dev.of_node. This is not this driver's responsibility.

 And then you add the id to the table below and matching is done
 automatically.

OK I see - it comes from mfd and it is easy enough to make it do the
right thing.

Thanks for your comments and patience. I will send a new patch.

Regards,
Simon


 Thanks.

 --
 Dmitry
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH v2 2/6] mfd: Add ChromeOS EC implementation

[Simon Glass]

Hi Joe,

On Tue, Feb 12, 2013 at 7:35 PM, Joe Perches j...@perches.com wrote:
 On Tue, 2013-02-12 at 18:42 -0800, Simon Glass wrote:
 This is the base EC implementation, which provides a high level
 interface to the EC for use by the rest of the kernel. The actual
 communcations is dealt with by a separate protocol driver which
 registers itself with this interface.

 trivial logging message comments...

Thanks - I will tidy these up in the next spin.


 diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
 []
 +struct cros_ec_device *cros_ec_alloc(const char *name)
 +{
 + struct cros_ec_device *ec_dev;
 +
 + ec_dev = kzalloc(sizeof(*ec_dev), GFP_KERNEL);
 + if (ec_dev == NULL) {
 + dev_err(ec_dev-dev, cannot allocate\n);

 allocation OOM messages aren't useful as there's
 a standard one on all allocs without __GFP_WARN

 +int cros_ec_register(struct cros_ec_device *ec_dev)
 +{
 []
 + ec_dev-din = kmalloc(ec_dev-din_size, GFP_KERNEL);
 + if (!ec_dev-din) {
 + err = -ENOMEM;
 + dev_err(dev, cannot allocate din\n);

 etc...

 + if (err) {
 + dev_err(dev, failed to add mfd devices);

 missing terminating newline



Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v4 2/6] mfd: Add ChromeOS EC implementation

[Simon Glass]

This is the base EC implementation, which provides a high level
interface to the EC for use by the rest of the kernel. The actual
communcations is dealt with by a separate protocol driver which
registers itself with this interface.

Interrupts are passed on through a notifier.

A simple message structure is used to pass messages to the
protocol driver.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Che-Liang Chiou clch...@chromium.org
Signed-off-by: Jonathan Kliegman kli...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Olof Johansson ol...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
Changes in v4:
- Fix up trvial logging comments
- Remove messages reporting out of memory
- Add compatible string for cros-ec-keyb
- Remove wake notifier and let drivers use their own handlers instead

Changes in v3: None
Changes in v2:
- Remove use of __devinit/__devexit

 Documentation/devicetree/bindings/mfd/cros-ec.txt |  56 ++
 drivers/mfd/Kconfig   |   8 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/cros_ec.c | 206 ++
 include/linux/mfd/cros_ec.h   | 189 
 5 files changed, 460 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
 create mode 100644 drivers/mfd/cros_ec.c
 create mode 100644 include/linux/mfd/cros_ec.h

diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt 
b/Documentation/devicetree/bindings/mfd/cros-ec.txt
new file mode 100644
index 000..e0e59c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -0,0 +1,56 @@
+ChromeOS Embedded Controller
+
+Google's ChromeOS EC is a Cortex-M device which talks to the AP and
+implements various function such as keyboard and battery charging.
+
+The EC can be connect through various means (I2C, SPI, LPC) and the
+compatible string used depends on the inteface. Each connection method has
+its own driver which connects to the top level interface-agnostic EC driver.
+Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
+the top-level driver.
+
+Required properties (I2C):
+- compatible: google,cros-ec-i2c
+- reg: I2C slave address
+
+Required properties (SPI):
+- compatible: google,cros-ec-spi
+- reg: SPI chip select
+
+Required properties (LPC):
+- compatible: google,cros-ec-lpc
+- reg: List of (IO address, size) pairs defining the interface uses
+
+
+Example for I2C:
+
+i2c@12CA {
+   cros-ec@1e {
+   reg = 0x1e;
+   compatible = google,cros-ec-i2c;
+   interrupts = 14 0;
+   interrupt-parent = wakeup_eint;
+   wakeup-source;
+   };
+
+
+Example for SPI:
+
+spi@131b {
+   ec@0 {
+   compatible = google,cros-ec-spi;
+   reg = 0x0;
+   interrupts = 14 0;
+   interrupt-parent = wakeup_eint;
+   wakeup-source;
+   spi-max-frequency = 500;
+   controller-data {
+   cs-gpio = gpf0 3 4 3 0;
+   samsung,spi-cs;
+   samsung,spi-feedback-delay = 2;
+   };
+   };
+};
+
+
+Example for LPC is not supplied as it is not yet implemented.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 671f5b1..837a16b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -21,6 +21,14 @@ config MFD_88PM860X
  select individual components like voltage regulators, RTC and
  battery-charger under the corresponding menus.
 
+config MFD_CROS_EC
+   bool Support ChromeOS Embedded Controller
+   help
+ If you say yes here you get support for the ChromeOS Embedded
+ Controller (EC) providing keyboard, battery and power services.
+ You also ned to enable the driver for the bus you are using. The
+ protocol for talking to the EC is defined by the bus driver.
+
 config MFD_88PM800
tristate Support Marvell 88PM800
depends on I2C=y  GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b90409c..967767d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM800)   += 88pm800.o 88pm80x.o
 obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
+obj-$(CONFIG_MFD_CROS_EC)  += cros_ec.o
 
 rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
new file mode 100644
index 000..2650d6e
--- /dev/null
+++ b/drivers/mfd/cros_ec.c
@@ -0,0 +1,206 @@
+/*
+ * ChromeOS EC multi-function device
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General

[PATCH v4 0/6] Add ChromeOS Embedded Controller support

[Simon Glass]

The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
line is used to indicate when the EC needs service.

Functions performed by the EC vary by platform, but typically include
battery charging, keyboard scanning and power sequencing.

This series includes support for the EC message protocol, and implements
a matrix keyboard handler for Linux using the protocol. The EC performs
key scanning and passes scan data in response to AP requests. This is
used on the Samsung ARM Chromebook. No driver is available for LPC at
present.

This series can in principle operate on any hardware, but for it to actually
work on the Samsung ARM Chromebook, it needs patches which are currently in
progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.

The driver is device-tree-enabled and a suitable binding is included in
this series. Example device tree nodes are included in the examples,
but no device tree patch for exynos5250-snow is provided at this stage, since
we must wait for the above-mentioned patches to land to avoid errors from
dtc. This can be added with a follow-on patch when that work is complete.

Changes in v4:
- Fix up trvial logging comments
- Remove messages reporting out of memory
- Add compatible string for cros-ec-keyb
- Remove wake notifier and let drivers use their own handlers instead
- Add 'depends on MFD_CROS_EC' to Kconfig
- Remove use of wake_notifier
- Remove manual code to locate device tree node
- Add resume handler to clear keyboard scan buffer if required

Changes in v3:
- Add stub for matrix_keypad_parse_of_params() when no CONFIG_OF
- Put back full DT range checking in tca8418 driver
- Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
- Remove old_state by using input layer's idev-key
- Move inner loop of cros_ec_keyb_has_ghosting() into its own function and 
simplify
- Add check for not finding the device tree node
- Remove comment about leaking matrix_keypad_build_keymap()
- Use platform_get_drvdata() where possible
- Remove call to input_free_device() after input_unregister_device()

Changes in v2:
- Remove use of __devinit/__devexit
- Remove use of __devinit/__devexit
- Remove use of __devinit/__devexit
- Add new patch to decode matrix-keypad DT binding
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols

Simon Glass (6):
  mfd: Add ChromeOS EC messages header
  mfd: Add ChromeOS EC implementation
  mfd: Add ChromeOS EC I2C driver
  mfd: Add ChromeOS EC SPI driver
  Input: matrix-keymap: Add function to read the new DT binding
  Input: Add ChromeOS EC keyboard driver

 .../devicetree/bindings/input/cros-ec-keyb.txt |   72 +
 Documentation/devicetree/bindings/mfd/cros-ec.txt  |   56 +
 drivers/input/keyboard/Kconfig |   12 +
 drivers/input/keyboard/Makefile|1 +
 drivers/input/keyboard/cros_ec_keyb.c  |  356 +
 drivers/input/keyboard/lpc32xx-keys.c  |   11 +-
 drivers/input/keyboard/omap4-keypad.c  |   16 +-
 drivers/input/keyboard/tca8418_keypad.c|7 +-
 drivers/input/matrix-keymap.c  |   19 +
 drivers/mfd/Kconfig|   28 +
 drivers/mfd/Makefile   |3 +
 drivers/mfd/cros_ec.c  |  206 +++
 drivers/mfd/cros_ec_i2c.c  |  262 
 drivers/mfd/cros_ec_spi.c  |  412 ++
 include/linux/input/matrix_keypad.h|   19 +
 include/linux/mfd/cros_ec.h|  189 +++
 include/linux/mfd/cros_ec_commands.h   | 1369 
 17 files changed, 3020 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
 create mode 100644 drivers/mfd/cros_ec.c
 create mode 100644 drivers/mfd/cros_ec_i2c.c
 create mode 100644 drivers/mfd/cros_ec_spi.c
 create mode 100644 include/linux/mfd/cros_ec.h
 create mode 100644 include/linux/mfd/cros_ec_commands.h

-- 
1.8.1.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v4 6/6] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Use the key-matrix layer to interpret key scan information from the EC
and inject input based on the FDT-supplied key map. This driver registers
itself with the ChromeOS EC driver to perform communications.

The matrix-keypad FDT binding is used with a small addition to control
ghosting.

Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
Changes in v4:
- Add 'depends on MFD_CROS_EC' to Kconfig
- Remove use of wake_notifier
- Remove manual code to locate device tree node
- Add resume handler to clear keyboard scan buffer if required

Changes in v3:
- Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
- Remove old_state by using input layer's idev-key
- Move inner loop of cros_ec_keyb_has_ghosting() into its own function and 
simplify
- Add check for not finding the device tree node
- Remove comment about leaking matrix_keypad_build_keymap()
- Use platform_get_drvdata() where possible
- Remove call to input_free_device() after input_unregister_device()

Changes in v2:
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols

 .../devicetree/bindings/input/cros-ec-keyb.txt |  72 +
 drivers/input/keyboard/Kconfig |  12 +
 drivers/input/keyboard/Makefile|   1 +
 drivers/input/keyboard/cros_ec_keyb.c  | 356 +
 4 files changed, 441 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c

diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt 
b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000..0f6355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: google,cros-ec-keyb
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+   compatible = google,cros-ec-keyb;
+   keypad,num-rows = 8;
+   keypad,num-columns = 13;
+   google,needs-ghost-filter;
+   /*
+* Keymap entries take the form of 0xRRCC where
+* RR=Row CC=Column =Key Code
+* The values below are for a US keyboard layout and
+* are taken from the Linux driver. Note that the
+* 102ND key is not used for US keyboards.
+*/
+   linux,keymap = 
+   /* CAPSLCK F1 B  F10 */
+   0x0001003a 0x0002003b 0x00030030 0x00040044
+   /* N   =  R_ALT  ESC */
+   0x00060031 0x0008000d 0x000a0064 0x01010001
+   /* F4  G  F7 H   */
+   0x0102003e 0x01030022 0x01040041 0x01060023
+   /* '   F9 BKSPACEL_CTRL  */
+   0x01080028 0x01090043 0x010b000e 0x021d
+   /* TAB F3 T  F6  */
+   0x0201000f 0x0202003d 0x02030014 0x02040040
+   /* ]   Y  102ND  [   */
+   0x0205001b 0x02060015 0x02070056 0x0208001a
+   /* F8  GRAVE  F2 5   */
+   0x02090042 0x03010029 0x0302003c 0x03030006
+   /* F5  6  -  \   */
+   0x0304003f 0x03060007 0x0308000c 0x030b002b
+   /* R_CTRL  A  D  F   */
+   0x0461 0x0401001e 0x04020020 0x04030021
+   /* S   K  J  ;   */
+   0x0404001f 0x04050025 0x04060024 0x04080027
+   /* L   ENTER  Z  C   */
+   0x04090026 0x040b001c 0x0501002c 0x0502002e
+   /* V   X  ,  M   */
+   0x0503002f 0x0504002d 0x05050033 0x05060032
+   /* L_SHIFT /  .  SPACE   */
+   0x0507002a 0x05080035 0x05090034 0x050B0039
+   /* 1   3  4  2   */
+   0x06010002 0x06020004 0x06030005 0x06040003
+   /* 8   7  0  9   */
+   0x06050009 0x06060008 0x0608000b 0x0609000a
+   /* L_ALT   DOWN   RIGHT  Q   */
+   0x060a0038 0x060b006c 0x060c006a

Re: [PATCH v2 6/6] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Hi Dmitry,

On Wed, Feb 13, 2013 at 12:02 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 Hi SImon,

 On Tue, Feb 12, 2013 at 06:42:26PM -0800, Simon Glass wrote:
 Use the key-matrix layer to interpret key scan information from the EC
 and inject input based on the FDT-supplied key map. This driver registers
 itself with the ChromeOS EC driver to perform communications.

 Additional FDT bindings are provided to specify rows/columns and the
 auto-repeat information.

 Signed-off-by: Simon Glass s...@chromium.org
 Signed-off-by: Luigi Semenzato semenz...@chromium.org
 Signed-off-by: Vincent Palatin vpala...@chromium.org
 ---
 Changes in v2:
 - Remove use of __devinit/__devexit
 - Use function to read matrix-keypad parameters from DT
 - Remove key autorepeat parameters from DT binding and driver
 - Use unsigned int for rows/cols

Thanks for all the review comments.


  .../devicetree/bindings/input/cros-ec-keyb.txt |  72 
  drivers/input/keyboard/Kconfig |  12 +
  drivers/input/keyboard/Makefile|   1 +
  drivers/input/keyboard/cros_ec_keyb.c  | 394 
 +
  4 files changed, 479 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
  create mode 100644 drivers/input/keyboard/cros_ec_keyb.c

 diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt 
 b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 new file mode 100644
 index 000..0f6355c
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 @@ -0,0 +1,72 @@
 +ChromeOS EC Keyboard
 +
 +Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
 +a separate EC (Embedded Controller) device. It provides a message for 
 reading
 +key scans from the EC. These are then converted into keycodes for processing
 +by the kernel.
 +
 +This binding is based on matrix-keymap.txt and extends/modifies it as 
 follows:
 +
 +Required properties:
 +- compatible: google,cros-ec-keyb
 +
 +Optional properties:
 +- google,needs-ghost-filter: True to enable a ghost filter for the matrix
 +keyboard. This is recommended if the EC does not have its own logic or
 +hardware for this.
 +
 +
 +Example:
 +
 +cros-ec-keyb {
 + compatible = google,cros-ec-keyb;
 + keypad,num-rows = 8;
 + keypad,num-columns = 13;
 + google,needs-ghost-filter;
 + /*
 +  * Keymap entries take the form of 0xRRCC where
 +  * RR=Row CC=Column =Key Code
 +  * The values below are for a US keyboard layout and
 +  * are taken from the Linux driver. Note that the
 +  * 102ND key is not used for US keyboards.
 +  */
 + linux,keymap = 
 + /* CAPSLCK F1 B  F10 */
 + 0x0001003a 0x0002003b 0x00030030 0x00040044
 + /* N   =  R_ALT  ESC */
 + 0x00060031 0x0008000d 0x000a0064 0x01010001
 + /* F4  G  F7 H   */
 + 0x0102003e 0x01030022 0x01040041 0x01060023
 + /* '   F9 BKSPACEL_CTRL  */
 + 0x01080028 0x01090043 0x010b000e 0x021d
 + /* TAB F3 T  F6  */
 + 0x0201000f 0x0202003d 0x02030014 0x02040040
 + /* ]   Y  102ND  [   */
 + 0x0205001b 0x02060015 0x02070056 0x0208001a
 + /* F8  GRAVE  F2 5   */
 + 0x02090042 0x03010029 0x0302003c 0x03030006
 + /* F5  6  -  \   */
 + 0x0304003f 0x03060007 0x0308000c 0x030b002b
 + /* R_CTRL  A  D  F   */
 + 0x0461 0x0401001e 0x04020020 0x04030021
 + /* S   K  J  ;   */
 + 0x0404001f 0x04050025 0x04060024 0x04080027
 + /* L   ENTER  Z  C   */
 + 0x04090026 0x040b001c 0x0501002c 0x0502002e
 + /* V   X  ,  M   */
 + 0x0503002f 0x0504002d 0x05050033 0x05060032
 + /* L_SHIFT /  .  SPACE   */
 + 0x0507002a 0x05080035 0x05090034 0x050B0039
 + /* 1   3  4  2   */
 + 0x06010002 0x06020004 0x06030005 0x06040003
 + /* 8   7  0  9   */
 + 0x06050009 0x06060008 0x0608000b 0x0609000a
 + /* L_ALT   DOWN   RIGHT  Q   */
 + 0x060a0038 0x060b006c 0x060c006a 0x07010010
 + /* E   R  W  I   */
 + 0x07020012 0x07030013 0x07040011 0x07050017
 + /* U   R_SHIFTP  O   */
 + 0x07060016 0x07070036 0x07080019 0x07090018
 + /* UP  LEFT*/
 + 0x070b0067 0x070c0069;
 +};
 diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
 index

[PATCH v3 6/6] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Use the key-matrix layer to interpret key scan information from the EC
and inject input based on the FDT-supplied key map. This driver registers
itself with the ChromeOS EC driver to perform communications.

The matrix-keypad FDT binding is used with a small addition to control
ghosting.

Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
Changes in v3:
- Remove 'select MFD_CROS_EC' from Kconfig as it isn't necessary
- Remove old_state by using input layer's idev-key
- Move inner loop of cros_ec_keyb_has_ghosting() into its own function and 
simplify
- Add check for not finding the device tree node
- Remove comment about leaking matrix_keypad_build_keymap()
- Use platform_get_drvdata() where possible
- Remove call to input_free_device() after input_unregister_device()

Changes in v2:
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols

 .../devicetree/bindings/input/cros-ec-keyb.txt |  72 
 drivers/input/keyboard/Kconfig |  11 +
 drivers/input/keyboard/Makefile|   1 +
 drivers/input/keyboard/cros_ec_keyb.c  | 364 +
 4 files changed, 448 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c

diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt 
b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000..0f6355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: google,cros-ec-keyb
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+   compatible = google,cros-ec-keyb;
+   keypad,num-rows = 8;
+   keypad,num-columns = 13;
+   google,needs-ghost-filter;
+   /*
+* Keymap entries take the form of 0xRRCC where
+* RR=Row CC=Column =Key Code
+* The values below are for a US keyboard layout and
+* are taken from the Linux driver. Note that the
+* 102ND key is not used for US keyboards.
+*/
+   linux,keymap = 
+   /* CAPSLCK F1 B  F10 */
+   0x0001003a 0x0002003b 0x00030030 0x00040044
+   /* N   =  R_ALT  ESC */
+   0x00060031 0x0008000d 0x000a0064 0x01010001
+   /* F4  G  F7 H   */
+   0x0102003e 0x01030022 0x01040041 0x01060023
+   /* '   F9 BKSPACEL_CTRL  */
+   0x01080028 0x01090043 0x010b000e 0x021d
+   /* TAB F3 T  F6  */
+   0x0201000f 0x0202003d 0x02030014 0x02040040
+   /* ]   Y  102ND  [   */
+   0x0205001b 0x02060015 0x02070056 0x0208001a
+   /* F8  GRAVE  F2 5   */
+   0x02090042 0x03010029 0x0302003c 0x03030006
+   /* F5  6  -  \   */
+   0x0304003f 0x03060007 0x0308000c 0x030b002b
+   /* R_CTRL  A  D  F   */
+   0x0461 0x0401001e 0x04020020 0x04030021
+   /* S   K  J  ;   */
+   0x0404001f 0x04050025 0x04060024 0x04080027
+   /* L   ENTER  Z  C   */
+   0x04090026 0x040b001c 0x0501002c 0x0502002e
+   /* V   X  ,  M   */
+   0x0503002f 0x0504002d 0x05050033 0x05060032
+   /* L_SHIFT /  .  SPACE   */
+   0x0507002a 0x05080035 0x05090034 0x050B0039
+   /* 1   3  4  2   */
+   0x06010002 0x06020004 0x06030005 0x06040003
+   /* 8   7  0  9   */
+   0x06050009 0x06060008 0x0608000b 0x0609000a
+   /* L_ALT   DOWN   RIGHT  Q   */
+   0x060a0038 0x060b006c 0x060c006a 0x07010010
+   /* E   R  W  I   */
+   0x07020012 0x07030013 0x07040011 0x07050017
+   /* U   R_SHIFTP  O

Re: [PATCH 0/5] Add ChromeOS Embedded Controller support

[Simon Glass]

Hi Samuel,

On Wed, Dec 12, 2012 at 1:33 PM, Simon Glass s...@chromium.org wrote:
 (get_maintainer.pl has produced an enormous list - I hope you are all
 interested.)

 The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
 used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
 connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
 line is used to indicate when the EC needs service.

 Functions performed by the EC vary by platform, but typically include
 battery charging, keyboard scanning and power sequencing.

 This series includes support for the EC message protocol, and implements
 a matrix keyboard handler for Linux using the protocol. The EC performs
 key scanning and passes scan data in response to AP requests. This is
 used on the Samsung ARM Chromebook. No driver is available for LPC at
 present.

 This series can in principle operate on any hardware, but for it to actually
 work on the Samsung ARM Chromebook, it needs patches which are currently in
 progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.

 The driver is device-tree-enabled and a suitable binding is included in
 this series. Example device tree nodes are included in the examples,
 but no device tree patch for exynos5250-snow is provided at this stage, since
 we must wait for the above-mentioned patches to land to avoid errors from
 dtc. This can be added with a follow-on patch when that work is complete.


 Simon Glass (5):
   mfd: Add ChromeOS EC messages header
   mfd: Add ChromeOS EC implementation
   mfd: Add ChromeOS EC I2C driver
   mfd: Add ChromeOS EC SPI driver
   Input: Add ChromeOS EC keyboard driver

Are you planning to pick the mfd part of this series please? I am
going to send a new version of the input patch on its own now that the
DT binding is agreed.

Regards,
Simon


  .../devicetree/bindings/input/cros-ec-keyb.txt |   77 ++
  Documentation/devicetree/bindings/mfd/cros-ec.txt  |   56 +
  drivers/input/keyboard/Kconfig |   10 +
  drivers/input/keyboard/Makefile|1 +
  drivers/input/keyboard/cros_ec_keyb.c  |  413 ++
  drivers/mfd/Kconfig|   28 +
  drivers/mfd/Makefile   |3 +
  drivers/mfd/cros_ec.c  |  219 
  drivers/mfd/cros_ec_i2c.c  |  262 
  drivers/mfd/cros_ec_spi.c  |  412 ++
  include/linux/mfd/cros_ec.h|  190 +++
  include/linux/mfd/cros_ec_commands.h   | 1369 
 
  12 files changed, 3040 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
  create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
  create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
  create mode 100644 drivers/mfd/cros_ec.c
  create mode 100644 drivers/mfd/cros_ec_i2c.c
  create mode 100644 drivers/mfd/cros_ec_spi.c
  create mode 100644 include/linux/mfd/cros_ec.h
  create mode 100644 include/linux/mfd/cros_ec_commands.h

 --
 1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 0/5] Add ChromeOS Embedded Controller support

[Simon Glass]

Hi Samuel,

On Tue, Feb 12, 2013 at 4:37 PM, Simon Glass s...@chromium.org wrote:
 Hi Samuel,

 On Wed, Dec 12, 2012 at 1:33 PM, Simon Glass s...@chromium.org wrote:
 (get_maintainer.pl has produced an enormous list - I hope you are all
 interested.)

 The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
 used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
 connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
 line is used to indicate when the EC needs service.

 Functions performed by the EC vary by platform, but typically include
 battery charging, keyboard scanning and power sequencing.

 This series includes support for the EC message protocol, and implements
 a matrix keyboard handler for Linux using the protocol. The EC performs
 key scanning and passes scan data in response to AP requests. This is
 used on the Samsung ARM Chromebook. No driver is available for LPC at
 present.

 This series can in principle operate on any hardware, but for it to actually
 work on the Samsung ARM Chromebook, it needs patches which are currently in
 progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.

 The driver is device-tree-enabled and a suitable binding is included in
 this series. Example device tree nodes are included in the examples,
 but no device tree patch for exynos5250-snow is provided at this stage, since
 we must wait for the above-mentioned patches to land to avoid errors from
 dtc. This can be added with a follow-on patch when that work is complete.


 Simon Glass (5):
   mfd: Add ChromeOS EC messages header
   mfd: Add ChromeOS EC implementation
   mfd: Add ChromeOS EC I2C driver
   mfd: Add ChromeOS EC SPI driver
   Input: Add ChromeOS EC keyboard driver

 Are you planning to pick the mfd part of this series please? I am
 going to send a new version of the input patch on its own now that the
 DT binding is agreed.

Actually I see that __devinit/__devexit are gone in next/master. I
will resend the whole series again as v2. The first four patches are
for mfd and there will be two more for input.

Regards,
Simon


  .../devicetree/bindings/input/cros-ec-keyb.txt |   77 ++
  Documentation/devicetree/bindings/mfd/cros-ec.txt  |   56 +
  drivers/input/keyboard/Kconfig |   10 +
  drivers/input/keyboard/Makefile|1 +
  drivers/input/keyboard/cros_ec_keyb.c  |  413 ++
  drivers/mfd/Kconfig|   28 +
  drivers/mfd/Makefile   |3 +
  drivers/mfd/cros_ec.c  |  219 
  drivers/mfd/cros_ec_i2c.c  |  262 
  drivers/mfd/cros_ec_spi.c  |  412 ++
  include/linux/mfd/cros_ec.h|  190 +++
  include/linux/mfd/cros_ec_commands.h   | 1369 
 
  12 files changed, 3040 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
  create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
  create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
  create mode 100644 drivers/mfd/cros_ec.c
  create mode 100644 drivers/mfd/cros_ec_i2c.c
  create mode 100644 drivers/mfd/cros_ec_spi.c
  create mode 100644 include/linux/mfd/cros_ec.h
  create mode 100644 include/linux/mfd/cros_ec_commands.h

 --
 1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v2 0/6] Add ChromeOS Embedded Controller support

[Simon Glass]

The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
line is used to indicate when the EC needs service.

Functions performed by the EC vary by platform, but typically include
battery charging, keyboard scanning and power sequencing.

This series includes support for the EC message protocol, and implements
a matrix keyboard handler for Linux using the protocol. The EC performs
key scanning and passes scan data in response to AP requests. This is
used on the Samsung ARM Chromebook. No driver is available for LPC at
present.

This series can in principle operate on any hardware, but for it to actually
work on the Samsung ARM Chromebook, it needs patches which are currently in
progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.

The driver is device-tree-enabled and a suitable binding is included in
this series. Example device tree nodes are included in the examples,
but no device tree patch for exynos5250-snow is provided at this stage, since
we must wait for the above-mentioned patches to land to avoid errors from
dtc. This can be added with a follow-on patch when that work is complete.

Changes in v2:
- Remove use of __devinit/__devexit
- Remove use of __devinit/__devexit
- Remove use of __devinit/__devexit
- Add new patch to decode matrix-keypad DT binding
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols

Simon Glass (6):
  mfd: Add ChromeOS EC messages header
  mfd: Add ChromeOS EC implementation
  mfd: Add ChromeOS EC I2C driver
  mfd: Add ChromeOS EC SPI driver
  Input: matrix-keymap: Add function to read the new DT binding
  Input: Add ChromeOS EC keyboard driver

 .../devicetree/bindings/input/cros-ec-keyb.txt |   72 +
 Documentation/devicetree/bindings/mfd/cros-ec.txt  |   56 +
 drivers/input/keyboard/Kconfig |   12 +
 drivers/input/keyboard/Makefile|1 +
 drivers/input/keyboard/cros_ec_keyb.c  |  394 ++
 drivers/input/keyboard/lpc32xx-keys.c  |   11 +-
 drivers/input/keyboard/omap4-keypad.c  |   16 +-
 drivers/input/keyboard/tca8418_keypad.c|   11 +-
 drivers/input/matrix-keymap.c  |   20 +
 drivers/mfd/Kconfig|   28 +
 drivers/mfd/Makefile   |3 +
 drivers/mfd/cros_ec.c  |  219 
 drivers/mfd/cros_ec_i2c.c  |  262 
 drivers/mfd/cros_ec_spi.c  |  412 ++
 include/linux/input/matrix_keypad.h|   11 +
 include/linux/mfd/cros_ec.h|  190 +++
 include/linux/mfd/cros_ec_commands.h   | 1369 
 17 files changed, 3067 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
 create mode 100644 drivers/mfd/cros_ec.c
 create mode 100644 drivers/mfd/cros_ec_i2c.c
 create mode 100644 drivers/mfd/cros_ec_spi.c
 create mode 100644 include/linux/mfd/cros_ec.h
 create mode 100644 include/linux/mfd/cros_ec_commands.h

-- 
1.8.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v2 2/6] mfd: Add ChromeOS EC implementation

[Simon Glass]

This is the base EC implementation, which provides a high level
interface to the EC for use by the rest of the kernel. The actual
communcations is dealt with by a separate protocol driver which
registers itself with this interface.

Interrupts are passed on through a notifier. The driver supports
resume notification also, in case drivers wish to perform some
action there.

A simple message structure is used to pass messages to the
protocol driver.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Che-Liang Chiou clch...@chromium.org
Signed-off-by: Jonathan Kliegman kli...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Olof Johansson ol...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
Changes in v2:
- Remove use of __devinit/__devexit

 Documentation/devicetree/bindings/mfd/cros-ec.txt |  56 ++
 drivers/mfd/Kconfig   |   8 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/cros_ec.c | 219 ++
 include/linux/mfd/cros_ec.h   | 190 +++
 5 files changed, 474 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
 create mode 100644 drivers/mfd/cros_ec.c
 create mode 100644 include/linux/mfd/cros_ec.h

diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt 
b/Documentation/devicetree/bindings/mfd/cros-ec.txt
new file mode 100644
index 000..e0e59c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -0,0 +1,56 @@
+ChromeOS Embedded Controller
+
+Google's ChromeOS EC is a Cortex-M device which talks to the AP and
+implements various function such as keyboard and battery charging.
+
+The EC can be connect through various means (I2C, SPI, LPC) and the
+compatible string used depends on the inteface. Each connection method has
+its own driver which connects to the top level interface-agnostic EC driver.
+Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
+the top-level driver.
+
+Required properties (I2C):
+- compatible: google,cros-ec-i2c
+- reg: I2C slave address
+
+Required properties (SPI):
+- compatible: google,cros-ec-spi
+- reg: SPI chip select
+
+Required properties (LPC):
+- compatible: google,cros-ec-lpc
+- reg: List of (IO address, size) pairs defining the interface uses
+
+
+Example for I2C:
+
+i2c@12CA {
+   cros-ec@1e {
+   reg = 0x1e;
+   compatible = google,cros-ec-i2c;
+   interrupts = 14 0;
+   interrupt-parent = wakeup_eint;
+   wakeup-source;
+   };
+
+
+Example for SPI:
+
+spi@131b {
+   ec@0 {
+   compatible = google,cros-ec-spi;
+   reg = 0x0;
+   interrupts = 14 0;
+   interrupt-parent = wakeup_eint;
+   wakeup-source;
+   spi-max-frequency = 500;
+   controller-data {
+   cs-gpio = gpf0 3 4 3 0;
+   samsung,spi-cs;
+   samsung,spi-feedback-delay = 2;
+   };
+   };
+};
+
+
+Example for LPC is not supplied as it is not yet implemented.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 671f5b1..837a16b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -21,6 +21,14 @@ config MFD_88PM860X
  select individual components like voltage regulators, RTC and
  battery-charger under the corresponding menus.
 
+config MFD_CROS_EC
+   bool Support ChromeOS Embedded Controller
+   help
+ If you say yes here you get support for the ChromeOS Embedded
+ Controller (EC) providing keyboard, battery and power services.
+ You also ned to enable the driver for the bus you are using. The
+ protocol for talking to the EC is defined by the bus driver.
+
 config MFD_88PM800
tristate Support Marvell 88PM800
depends on I2C=y  GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b90409c..967767d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM800)   += 88pm800.o 88pm80x.o
 obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
+obj-$(CONFIG_MFD_CROS_EC)  += cros_ec.o
 
 rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
new file mode 100644
index 000..fc7fce3
--- /dev/null
+++ b/drivers/mfd/cros_ec.c
@@ -0,0 +1,219 @@
+/*
+ * ChromeOS EC multi-function device
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified

[PATCH v2 6/6] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Use the key-matrix layer to interpret key scan information from the EC
and inject input based on the FDT-supplied key map. This driver registers
itself with the ChromeOS EC driver to perform communications.

Additional FDT bindings are provided to specify rows/columns and the
auto-repeat information.

Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
Changes in v2:
- Remove use of __devinit/__devexit
- Use function to read matrix-keypad parameters from DT
- Remove key autorepeat parameters from DT binding and driver
- Use unsigned int for rows/cols

 .../devicetree/bindings/input/cros-ec-keyb.txt |  72 
 drivers/input/keyboard/Kconfig |  12 +
 drivers/input/keyboard/Makefile|   1 +
 drivers/input/keyboard/cros_ec_keyb.c  | 394 +
 4 files changed, 479 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c

diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt 
b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000..0f6355c
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,72 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
+
+Required properties:
+- compatible: google,cros-ec-keyb
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+   compatible = google,cros-ec-keyb;
+   keypad,num-rows = 8;
+   keypad,num-columns = 13;
+   google,needs-ghost-filter;
+   /*
+* Keymap entries take the form of 0xRRCC where
+* RR=Row CC=Column =Key Code
+* The values below are for a US keyboard layout and
+* are taken from the Linux driver. Note that the
+* 102ND key is not used for US keyboards.
+*/
+   linux,keymap = 
+   /* CAPSLCK F1 B  F10 */
+   0x0001003a 0x0002003b 0x00030030 0x00040044
+   /* N   =  R_ALT  ESC */
+   0x00060031 0x0008000d 0x000a0064 0x01010001
+   /* F4  G  F7 H   */
+   0x0102003e 0x01030022 0x01040041 0x01060023
+   /* '   F9 BKSPACEL_CTRL  */
+   0x01080028 0x01090043 0x010b000e 0x021d
+   /* TAB F3 T  F6  */
+   0x0201000f 0x0202003d 0x02030014 0x02040040
+   /* ]   Y  102ND  [   */
+   0x0205001b 0x02060015 0x02070056 0x0208001a
+   /* F8  GRAVE  F2 5   */
+   0x02090042 0x03010029 0x0302003c 0x03030006
+   /* F5  6  -  \   */
+   0x0304003f 0x03060007 0x0308000c 0x030b002b
+   /* R_CTRL  A  D  F   */
+   0x0461 0x0401001e 0x04020020 0x04030021
+   /* S   K  J  ;   */
+   0x0404001f 0x04050025 0x04060024 0x04080027
+   /* L   ENTER  Z  C   */
+   0x04090026 0x040b001c 0x0501002c 0x0502002e
+   /* V   X  ,  M   */
+   0x0503002f 0x0504002d 0x05050033 0x05060032
+   /* L_SHIFT /  .  SPACE   */
+   0x0507002a 0x05080035 0x05090034 0x050B0039
+   /* 1   3  4  2   */
+   0x06010002 0x06020004 0x06030005 0x06040003
+   /* 8   7  0  9   */
+   0x06050009 0x06060008 0x0608000b 0x0609000a
+   /* L_ALT   DOWN   RIGHT  Q   */
+   0x060a0038 0x060b006c 0x060c006a 0x07010010
+   /* E   R  W  I   */
+   0x07020012 0x07030013 0x07040011 0x07050017
+   /* U   R_SHIFTP  O   */
+   0x07060016 0x07070036 0x07080019 0x07090018
+   /* UP  LEFT*/
+   0x070b0067 0x070c0069;
+};
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 078305e..3a70be7 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -628,4 +628,16 @@ config KEYBOARD_W90P910
  To compile this driver as a module, choose M here

Re: [PATCH 7/8] Remove fdtdump and use fdtgrep instead

[Simon Glass]

Hi David,

On Tue, Feb 5, 2013 at 11:16 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
 On Mon, Jan 21, 2013 at 12:59:21PM -0800, Simon Glass wrote:
 Since fdtgrep does everything that fdtdump does now, perhaps we should
 replace it with a symlink.

 Nack.  The point of fdtdump is not simply to be a tool for dumping
 device trees - dtc -I dtb -O dts will do that already.  The point is
 to be a really simple, independent implementation of dumping the tree,
 which can be used for analyzing bugs in the more complex tools.

Sounds reasonable - I wasn't aware of that. I figured that if I didn't
send a patch to implement dump with grep then someone would ask for
it... But I agree it is nice to keep the simple code and I have made
the output function common anyway.

Regards,
Simon


 --
 David Gibson| I'll have my music baroque, and my code
 david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
 | _way_ _around_!
 http://www.ozlabs.org/~dgibson
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v2 1/8] Adjust util_is_printable_string() comment and fix test

[Simon Glass]

This commit which changed the behaviour of this function broke one
of the tests. Also the comment should be updated to reflect its new
behaviour.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Add new test to check byte output of a string list property

 tests/run_tests.sh | 3 ++-
 util.h | 8 +---
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index dd7f217..b56b626 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -498,9 +498,10 @@ fdtget_tests () {
 
 # run_fdtget_test expected-result [flags] file node property
 run_fdtget_test MyBoardName $dtb / model
+run_fdtget_test MyBoardName MyBoardFamilyName $dtb / compatible
 run_fdtget_test 77 121 66 111 \
 97 114 100 78 97 109 101 0 77 121 66 111 97 114 100 70 97 109 105 \
-108 121 78 97 109 101 0 $dtb / compatible
+108 121 78 97 109 101 0 -t bu $dtb / compatible
 run_fdtget_test MyBoardName MyBoardFamilyName -t s $dtb / compatible
 run_fdtget_test 32768 $dtb /cpus/PowerPC,970@1 d-cache-size
 run_fdtget_test 8000 -tx $dtb /cpus/PowerPC,970@1 d-cache-size
diff --git a/util.h b/util.h
index c8eb45d..e9043be 100644
--- a/util.h
+++ b/util.h
@@ -57,12 +57,14 @@ extern char *xstrdup(const char *s);
 extern char *join_path(const char *path, const char *name);
 
 /**
- * Check a string of a given length to see if it is all printable and
- * has a valid terminator.
+ * Check a property of a given length to see if it is all printable and
+ * has a valid terminator. The property can contain either a single string,
+ * or multiple strings each of non-zero length.
  *
  * @param data The string to check
  * @param len  The string length including terminator
- * @return 1 if a valid printable string, 0 if not */
+ * @return 1 if a valid printable string, 0 if not
+ */
 int util_is_printable_string(const void *data, int len);
 
 /*
-- 
1.8.1

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/8] Adjust util_is_printable_string() comment and fix test

[Simon Glass]

Hi David,

On Tue, Jan 22, 2013 at 6:33 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
 On Mon, Jan 21, 2013 at 12:59:15PM -0800, Simon Glass wrote:
 This commit which changed the behaviour of this function broke one
 of the tests. Also the comment should be updated to reflect its new
 behaviour.

 Signed-off-by: Simon Glass s...@chromium.org

 Acked-by: David Gibson da...@gibson.dropbear.id.au

 Jon, please apply asap, regardless of what we do with the rest of this
 series, since it fixes up the ugly test failure we have right now.

 ---
  tests/run_tests.sh |4 +---
  util.h |8 +---
  2 files changed, 6 insertions(+), 6 deletions(-)

 diff --git a/tests/run_tests.sh b/tests/run_tests.sh
 index dd7f217..e04512c 100755
 --- a/tests/run_tests.sh
 +++ b/tests/run_tests.sh
 @@ -498,9 +498,7 @@ fdtget_tests () {

  # run_fdtget_test expected-result [flags] file node property
  run_fdtget_test MyBoardName $dtb / model
 -run_fdtget_test 77 121 66 111 \
 -97 114 100 78 97 109 101 0 77 121 66 111 97 114 100 70 97 109 105 \
 -108 121 78 97 109 101 0 $dtb / compatible
 +run_fdtget_test MyBoardName MyBoardFamilyName $dtb / compatible

 I would also like to see a test of the old-style behaviour still
 present, by explicitly enabling it with -t bu.

OK - I have sent a v2 of this patch.

Regards,
Simon


 --
 David Gibson| I'll have my music baroque, and my code
 david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
 | _way_ _around_!
 http://www.ozlabs.org/~dgibson
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 0/8] Introduce fdtgrep for subsetting and hashing FDTs

[Simon Glass]

This series adds a new function, fdt_find_regions() which maps FDT parts
such as nodes and properties to their regions in the FDT binary. The
function is then used to implement a grep utility for FDTs.

The function itself is quite simple and small, but this series adds tests
and a grep utility, so quite a bit of code is built on it.

The use for this function is twofold. Firstly it provides a convenient
way of performing a structure-aware grep of the tree. For example it is
possible to grep for a node and get all the properties associated with
that node. Trees can be subsetted easily, by specifying the nodes that
are required, and then writing out the regions returned by this function.
This is useful for small resource-constrained systems, such as boot
loaders, which want to use an FDT but do not need to know about all of
it. The full FDT can be grepped to pull out the few things that are
needed - this can be automatic and does not require the FDT source code.

This first use makes it easy to implement an FDT grep. Options are
provided to search for matching nodes (by name or compatible string),
properties and also for any of the above. It is possible to search for
non-matches also (useful for excluding a particular property from the
FDT, for example). The output is like fdtdump, but only with the regions
selected by the grep. Options are also provided to print the string table,
memory reservation table, etc. The fdtgrep utility can output valid
source, which can be used by dtc, but it can also directly output a new
.dtb binary.

Secondly it makes it easy to hash parts of the tree and detect changes.
The intent is to get a list of regions which will be invariant provided
those parts are invariant. For example, if you request a list of regions
for all nodes but exclude the property data, then you will get the
same region contents regardless of any change to data properties.

This second use is the subject of a recent series sent to the U-Boot
mailing list, to enhance FIT images to support verified boot. Briefly,
this works by signing configurations (consisting of particular kernel
and FDT combinations) so that the boot loader can verify that these
combinations are valid and permitted. Since a FIT image is in fact an
FDT, we need to be able to hash particular regions of the FDT for the
signing and verification process. This is done by using fdt_find_regions()
to select the data that needs to be hashed for a particular configuration.

The fdtgrep utility can fairly easily replace all of the functions of
fdtdump, so this series turns fdtdump into a symlink.


Simon Glass (8):
  Adjust util_is_printable_string() comment and fix test
  Move property-printing into util
  .gitignore: Add rule for *.patch
  Export fdt_stringlist_contains()
  libfdt: Add function to find regions in an FDT
  Add fdtgrep to grep and subset FDTs
  Remove fdtdump and use fdtgrep instead
  RFC: Check offset in fdt_string()

 .gitignore   |2 +
 Makefile |9 +-
 Makefile.utils   |7 +
 fdtdump.c|  172 ---
 fdtgrep.c|  789 ++
 libfdt/fdt_ro.c  |7 +-
 libfdt/fdt_wip.c |  311 
 libfdt/libfdt.h  |  156 ++
 tests/.gitignore |1 +
 tests/Makefile.tests |3 +-
 tests/grep.dts   |   23 ++
 tests/region_tree.c  |  324 +
 tests/run_tests.sh   |  357 ++-
 tests/tests.sh   |1 +
 util.c   |   37 +++
 util.h   |   22 ++-
 16 files changed, 2036 insertions(+), 185 deletions(-)
 delete mode 100644 fdtdump.c
 create mode 100644 fdtgrep.c
 create mode 100644 tests/grep.dts
 create mode 100644 tests/region_tree.c

-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 3/8] .gitignore: Add rule for *.patch

[Simon Glass]

Ignore any patch files that we find, since these are likely to be
used when sending patches upstream.

Signed-off-by: Simon Glass s...@chromium.org
---
 .gitignore |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 7cabc49..545b899 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,6 +1,7 @@
 *.o
 *.d
 *.a
+*.patch
 *.so
 *~
 *.tab.[ch]
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 1/8] Adjust util_is_printable_string() comment and fix test

[Simon Glass]

This commit which changed the behaviour of this function broke one
of the tests. Also the comment should be updated to reflect its new
behaviour.

Signed-off-by: Simon Glass s...@chromium.org
---
 tests/run_tests.sh |4 +---
 util.h |8 +---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index dd7f217..e04512c 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -498,9 +498,7 @@ fdtget_tests () {
 
 # run_fdtget_test expected-result [flags] file node property
 run_fdtget_test MyBoardName $dtb / model
-run_fdtget_test 77 121 66 111 \
-97 114 100 78 97 109 101 0 77 121 66 111 97 114 100 70 97 109 105 \
-108 121 78 97 109 101 0 $dtb / compatible
+run_fdtget_test MyBoardName MyBoardFamilyName $dtb / compatible
 run_fdtget_test MyBoardName MyBoardFamilyName -t s $dtb / compatible
 run_fdtget_test 32768 $dtb /cpus/PowerPC,970@1 d-cache-size
 run_fdtget_test 8000 -tx $dtb /cpus/PowerPC,970@1 d-cache-size
diff --git a/util.h b/util.h
index c8eb45d..e9043be 100644
--- a/util.h
+++ b/util.h
@@ -57,12 +57,14 @@ extern char *xstrdup(const char *s);
 extern char *join_path(const char *path, const char *name);
 
 /**
- * Check a string of a given length to see if it is all printable and
- * has a valid terminator.
+ * Check a property of a given length to see if it is all printable and
+ * has a valid terminator. The property can contain either a single string,
+ * or multiple strings each of non-zero length.
  *
  * @param data The string to check
  * @param len  The string length including terminator
- * @return 1 if a valid printable string, 0 if not */
+ * @return 1 if a valid printable string, 0 if not
+ */
 int util_is_printable_string(const void *data, int len);
 
 /*
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 2/8] Move property-printing into util

[Simon Glass]

The function that prints a property can be useful to other programs,
so move it into util.

Signed-off-by: Simon Glass s...@chromium.org
---
 fdtdump.c |   37 +
 util.c|   37 +
 util.h|   14 ++
 3 files changed, 52 insertions(+), 36 deletions(-)

diff --git a/fdtdump.c b/fdtdump.c
index b2c5b37..03ea429 100644
--- a/fdtdump.c
+++ b/fdtdump.c
@@ -17,41 +17,6 @@
 #define PALIGN(p, a)   ((void *)(ALIGN((unsigned long)(p), (a
 #define GET_CELL(p)(p += 4, *((const uint32_t *)(p-4)))
 
-static void print_data(const char *data, int len)
-{
-   int i;
-   const char *p = data;
-   const char *s;
-
-   /* no data, don't print */
-   if (len == 0)
-   return;
-
-   if (util_is_printable_string(data, len)) {
-   printf( = );
-
-   s = data;
-   do {
-   printf(\%s\, s);
-   s += strlen(s) + 1;
-   if (s  data + len)
-   printf(, );
-   } while (s  data + len);
-
-   } else if ((len % 4) == 0) {
-   printf( = );
-   for (i = 0; i  len; i += 4)
-   printf(0x%08x%s, fdt32_to_cpu(GET_CELL(p)),
-  i  (len - 4) ?   : );
-   printf();
-   } else {
-   printf( = [);
-   for (i = 0; i  len; i++)
-   printf(%02x%s, *p++, i  len - 1 ?   : );
-   printf(]);
-   }
-}
-
 static void dump_blob(void *blob)
 {
struct fdt_header *bph = blob;
@@ -147,7 +112,7 @@ static void dump_blob(void *blob)
p = PALIGN(p + sz, 4);
 
printf(%*s%s, depth * shift, , s);
-   print_data(t, sz);
+   utilfdt_print_data(t, sz);
printf(;\n);
}
 }
diff --git a/util.c b/util.c
index 45f186b..b081fa8 100644
--- a/util.c
+++ b/util.c
@@ -335,3 +335,40 @@ int utilfdt_decode_type(const char *fmt, int *type, int 
*size)
return -1;
return 0;
 }
+
+void utilfdt_print_data(const char *data, int len)
+{
+   int i;
+   const char *p = data;
+   const char *s;
+
+   /* no data, don't print */
+   if (len == 0)
+   return;
+
+   if (util_is_printable_string(data, len)) {
+   printf( = );
+
+   s = data;
+   do {
+   printf(\%s\, s);
+   s += strlen(s) + 1;
+   if (s  data + len)
+   printf(, );
+   } while (s  data + len);
+
+   } else if ((len % 4) == 0) {
+   const uint32_t *cell = (const uint32_t *)data;
+
+   printf( = );
+   for (i = 0; i  len; i += 4)
+   printf(0x%08x%s, fdt32_to_cpu(cell[i]),
+  i  (len - 4) ?   : );
+   printf();
+   } else {
+   printf( = [);
+   for (i = 0; i  len; i++)
+   printf(%02x%s, *p++, i  len - 1 ?   : );
+   printf(]);
+   }
+}
diff --git a/util.h b/util.h
index e9043be..543a173 100644
--- a/util.h
+++ b/util.h
@@ -152,4 +152,18 @@ int utilfdt_decode_type(const char *fmt, int *type, int 
*size);
\tOptional modifier prefix:\n \
\t\thh or b=byte, h=2 byte, l=4 byte (default)\n;
 
+/**
+ * Print property data in a readable format to stdout
+ *
+ * Properties that look like strings will be printed as strings. Otherwise
+ * the data will be displayed either as cells (if len is a multiple of 4
+ * bytes) or bytes.
+ *
+ * If len is 0 then this function does nothing.
+ *
+ * @param data Pointers to property data
+ * @param len  Length of property data
+ */
+void utilfdt_print_data(const char *data, int len);
+
 #endif /* _UTIL_H */
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 4/8] Export fdt_stringlist_contains()

[Simon Glass]

This function is useful outside libfdt, so export it.

Signed-off-by: Simon Glass s...@chromium.org
---
 libfdt/fdt_ro.c |5 ++---
 libfdt/libfdt.h |   14 ++
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/libfdt/fdt_ro.c b/libfdt/fdt_ro.c
index 42da2bd..50007f6 100644
--- a/libfdt/fdt_ro.c
+++ b/libfdt/fdt_ro.c
@@ -515,8 +515,7 @@ int fdt_node_offset_by_phandle(const void *fdt, uint32_t 
phandle)
return offset; /* error from fdt_next_node() */
 }
 
-static int _fdt_stringlist_contains(const char *strlist, int listlen,
-   const char *str)
+int fdt_stringlist_contains(const char *strlist, int listlen, const char *str)
 {
int len = strlen(str);
const char *p;
@@ -542,7 +541,7 @@ int fdt_node_check_compatible(const void *fdt, int 
nodeoffset,
prop = fdt_getprop(fdt, nodeoffset, compatible, len);
if (!prop)
return len;
-   if (_fdt_stringlist_contains(prop, len, compatible))
+   if (fdt_stringlist_contains(prop, len, compatible))
return 0;
else
return 1;
diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
index 8e57a06..c0075e7 100644
--- a/libfdt/libfdt.h
+++ b/libfdt/libfdt.h
@@ -816,6 +816,20 @@ int fdt_node_check_compatible(const void *fdt, int 
nodeoffset,
 int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
  const char *compatible);
 
+/**
+ * fdt_stringlist_contains - check a string list property for a string
+ * @strlist: Property containing a list of strings to check
+ * @listlen: Length of property
+ * @str: String to search for
+ *
+ * This is a utility function provided for convenience. The list contains
+ * one or more strings, each terminated by \0, as is found in a device tree
+ * compatible property.
+ *
+ * @return: 1 if the string is found in the list, 0 not found, or invalid list
+ */
+int fdt_stringlist_contains(const char *strlist, int listlen, const char *str);
+
 /**/
 /* Write-in-place functions   */
 /**/
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 8/8] RFC: Check offset in fdt_string()

[Simon Glass]

(We probably don't want this patch, and certainly can't apply it as is,
but I send it in order to find out the intent of fdt_string()).

At present fdt_string() says that returns:

   - a pointer to the string, on success
   - NULL, if stroffset is out of bounds

However it does not in fact return NULL. Changing it to do so also
breaks 15 tests (segfault).

What is the intended behaviour of this function, please?
Signed-off-by: Simon Glass s...@chromium.org
---
 libfdt/fdt_ro.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/libfdt/fdt_ro.c b/libfdt/fdt_ro.c
index 50007f6..cba8772 100644
--- a/libfdt/fdt_ro.c
+++ b/libfdt/fdt_ro.c
@@ -77,6 +77,8 @@ static int _fdt_nodename_eq(const void *fdt, int offset,
 
 const char *fdt_string(const void *fdt, int stroffset)
 {
+   if (stroffset  0 || stroffset = fdt_size_dt_strings(fdt))
+   return NULL;
return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
 }
 
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 5/8] libfdt: Add function to find regions in an FDT

[Simon Glass]

Given a set of nodes and properties, find the regions of the device tree
which describe those parts.

A test is provided which builds a tree while tracking where the regions
should be, then calls fdt_find_regions() to make sure that it agrees.

Further tests will come as part of fdtgrep.

Signed-off-by: Simon Glass s...@chromium.org
---
 libfdt/fdt_wip.c |  311 
 libfdt/libfdt.h  |  142 ++
 tests/.gitignore |1 +
 tests/Makefile.tests |3 +-
 tests/region_tree.c  |  324 ++
 tests/run_tests.sh   |5 +
 6 files changed, 785 insertions(+), 1 deletions(-)
 create mode 100644 tests/region_tree.c

diff --git a/libfdt/fdt_wip.c b/libfdt/fdt_wip.c
index c5bbb68..ff0f940 100644
--- a/libfdt/fdt_wip.c
+++ b/libfdt/fdt_wip.c
@@ -116,3 +116,314 @@ int fdt_nop_node(void *fdt, int nodeoffset)
endoffset - nodeoffset);
return 0;
 }
+
+/* Maximum depth that we can grep */
+#define FDT_MAX_DEPTH  32
+
+/* Decribes what we want to include from the current tag */
+enum want_t {
+   WANT_NOTHING,
+   WANT_NODES_ONLY,
+   WANT_NODES_AND_PROPS,
+};
+
+/* Keeps track of the state at parent nodes */
+struct fdt_subnode_stack {
+   int offset; /* Offset of node */
+   enum want_t want;   /* The 'want' value here */
+   int included;   /* 1 if we included this node, 0 if not */
+};
+
+/* The state of our finding algortihm */
+struct find_reg {
+   struct fdt_subnode_stack stack[FDT_MAX_DEPTH];  /* node stack */
+   struct fdt_region *region;  /* Contains list of regions found */
+   int count;  /* Numnber of regions found */
+   const void *fdt;/* FDT blob */
+   int max_regions;/* Maximum regions to find */
+   int can_merge;  /* 1 if we can merge with previous region */
+};
+
+/**
+ * fdt_add_region() - Add a new region to our list
+ *
+ * The region is added if there is space, but in any case we increment the
+ * count. If permitted, and the new region overlaps the last one, we merge
+ * them.
+ *
+ * @info: State information
+ * @offset: Start offset of region
+ * @size: Size of region
+ */
+static void fdt_add_region(struct find_reg *info, int offset, int size)
+{
+   struct fdt_region *reg = info-region[info-count - 1];
+
+   if (info-can_merge  info-count 
+   info-count  info-max_regions 
+   offset = reg-offset + reg-size) {
+   reg-size = offset + size - reg-offset;
+   } else if (info-count  info-max_regions) {
+   reg++;
+   reg-offset = offset;
+   reg-size = size;
+   info-count++;
+   }
+}
+
+/**
+ * fdt_include_supernodes() - Include supernodes required by this node
+ *
+ * When we decided to include a node or property which is not at the top
+ * level, this function forces the inclusion of higher level nodes. For
+ * example, given this tree:
+ *
+ * / {
+ * testing {
+ * }
+ * }
+ *
+ * If we decide to include testing then we need the root node to have a valid
+ * tree. This function adds those regions.
+ *
+ * @info: State information
+ * @depth: Current stack depth
+ */
+static void fdt_include_supernodes(struct find_reg *info, int depth)
+{
+   int base = fdt_off_dt_struct(info-fdt);
+   int start, stop_at;
+   int i;
+
+   /*
+* Work down the stack looking for supernodes that we didn't include.
+* The algortihm here is actually pretty simple, since we know that
+* no previous subnode had to include these nodes, or if it did, we
+* marked them as included (on the stack) already.
+*/
+   for (i = 0; i = depth; i++) {
+   if (!info-stack[i].included) {
+   start = info-stack[i].offset;
+
+   /* Add the FDT_BEGIN_NODE tag of this supernode */
+   fdt_next_tag(info-fdt, start, stop_at);
+   fdt_add_region(info, base + start, stop_at - start);
+
+   /* Remember that this supernode is now included */
+   info-stack[i].included = 1;
+   info-can_merge = 1;
+   }
+
+   /* Force (later) generation of the FDT_END_NODE tag */
+   if (!info-stack[i].want)
+   info-stack[i].want = WANT_NODES_ONLY;
+   }
+}
+
+int fdt_find_regions(const void *fdt,
+   int (*h_include)(void *priv, int type, const char *data,
+   int size),
+   void *priv,
+   struct fdt_region region[], int max_regions,
+   char *path, int path_len, int flags)
+{
+   int base = fdt_off_dt_struct(fdt);
+   struct find_reg info;
+   int nextoffset;
+   int start = -1;
+   int depth = -1

[PATCH 7/8] Remove fdtdump and use fdtgrep instead

[Simon Glass]

Since fdtgrep does everything that fdtdump does now, perhaps we should
replace it with a symlink.

Signed-off-by: Simon Glass s...@chromium.org
---
 Makefile  |5 +-
 fdtdump.c |  137 -
 fdtgrep.c |   40 --
 3 files changed, 30 insertions(+), 152 deletions(-)
 delete mode 100644 fdtdump.c

diff --git a/Makefile b/Makefile
index 96e0488..339b83c 100644
--- a/Makefile
+++ b/Makefile
@@ -122,7 +122,6 @@ all: $(BIN) libfdt
 ifneq ($(DEPTARGETS),)
 -include $(DTC_OBJS:%.o=%.d)
 -include $(CONVERT_OBJS:%.o=%.d)
--include $(FDTDUMP_OBJS:%.o=%.d)
 -include $(FDTGET_OBJS:%.o=%.d)
 -include $(FDTPUT_OBJS:%.o=%.d)
 -include $(FDTGREP_OBJS:%.o=%.d)
@@ -184,7 +183,9 @@ convert-dtsv0: $(CONVERT_OBJS)
@$(VECHO) LD $@
$(LINK.c) -o $@ $^
 
-fdtdump:   $(FDTDUMP_OBJS)
+fdtdump:   fdtgrep
+   rm -f $@
+   ln -s $ $@
 
 fdtget:$(FDTGET_OBJS) $(LIBFDT_archive)
 
diff --git a/fdtdump.c b/fdtdump.c
deleted file mode 100644
index 03ea429..000
--- a/fdtdump.c
+++ /dev/null
@@ -1,137 +0,0 @@
-/*
- * fdtdump.c - Contributed by Pantelis Antoniou pantelis.antoniou AT 
gmail.com
- */
-
-#include stdint.h
-#include stdio.h
-#include stdlib.h
-#include string.h
-#include ctype.h
-
-#include libfdt_env.h
-#include fdt.h
-
-#include util.h
-
-#define ALIGN(x, a)(((x) + ((a) - 1))  ~((a) - 1))
-#define PALIGN(p, a)   ((void *)(ALIGN((unsigned long)(p), (a
-#define GET_CELL(p)(p += 4, *((const uint32_t *)(p-4)))
-
-static void dump_blob(void *blob)
-{
-   struct fdt_header *bph = blob;
-   uint32_t off_mem_rsvmap = fdt32_to_cpu(bph-off_mem_rsvmap);
-   uint32_t off_dt = fdt32_to_cpu(bph-off_dt_struct);
-   uint32_t off_str = fdt32_to_cpu(bph-off_dt_strings);
-   struct fdt_reserve_entry *p_rsvmap =
-   (struct fdt_reserve_entry *)((char *)blob + off_mem_rsvmap);
-   const char *p_struct = (const char *)blob + off_dt;
-   const char *p_strings = (const char *)blob + off_str;
-   uint32_t version = fdt32_to_cpu(bph-version);
-   uint32_t totalsize = fdt32_to_cpu(bph-totalsize);
-   uint32_t tag;
-   const char *p, *s, *t;
-   int depth, sz, shift;
-   int i;
-   uint64_t addr, size;
-
-   depth = 0;
-   shift = 4;
-
-   printf(/dts-v1/;\n);
-   printf(// magic:\t\t0x%x\n, fdt32_to_cpu(bph-magic));
-   printf(// totalsize:\t\t0x%x (%d)\n, totalsize, totalsize);
-   printf(// off_dt_struct:\t0x%x\n, off_dt);
-   printf(// off_dt_strings:\t0x%x\n, off_str);
-   printf(// off_mem_rsvmap:\t0x%x\n, off_mem_rsvmap);
-   printf(// version:\t\t%d\n, version);
-   printf(// last_comp_version:\t%d\n,
-  fdt32_to_cpu(bph-last_comp_version));
-   if (version = 2)
-   printf(// boot_cpuid_phys:\t0x%x\n,
-  fdt32_to_cpu(bph-boot_cpuid_phys));
-
-   if (version = 3)
-   printf(// size_dt_strings:\t0x%x\n,
-  fdt32_to_cpu(bph-size_dt_strings));
-   if (version = 17)
-   printf(// size_dt_struct:\t0x%x\n,
-  fdt32_to_cpu(bph-size_dt_struct));
-   printf(\n);
-
-   for (i = 0; ; i++) {
-   addr = fdt64_to_cpu(p_rsvmap[i].address);
-   size = fdt64_to_cpu(p_rsvmap[i].size);
-   if (addr == 0  size == 0)
-   break;
-
-   printf(/memreserve/ %llx %llx;\n,
-  (unsigned long long)addr, (unsigned long long)size);
-   }
-
-   p = p_struct;
-   while ((tag = fdt32_to_cpu(GET_CELL(p))) != FDT_END) {
-
-   /* printf(tag: 0x%08x (%d)\n, tag, p - p_struct); */
-
-   if (tag == FDT_BEGIN_NODE) {
-   s = p;
-   p = PALIGN(p + strlen(s) + 1, 4);
-
-   if (*s == '\0')
-   s = /;
-
-   printf(%*s%s {\n, depth * shift, , s);
-
-   depth++;
-   continue;
-   }
-
-   if (tag == FDT_END_NODE) {
-   depth--;
-
-   printf(%*s};\n, depth * shift, );
-   continue;
-   }
-
-   if (tag == FDT_NOP) {
-   printf(%*s// [NOP]\n, depth * shift, );
-   continue;
-   }
-
-   if (tag != FDT_PROP) {
-   fprintf(stderr, %*s ** Unknown tag 0x%08x\n, depth * 
shift, , tag);
-   break;
-   }
-   sz = fdt32_to_cpu(GET_CELL(p));
-   s = p_strings + fdt32_to_cpu(GET_CELL(p));
-   if (version  16  sz = 8)
-   p = PALIGN(p, 8);
-   t = p;
-
-   p = PALIGN(p + sz, 4);
-
-   printf(%*s%s, depth * shift, , s);
-   utilfdt_print_data(t, sz

[PATCH 6/8] Add fdtgrep to grep and subset FDTs

[Simon Glass]

fdtgrep operates like a grep for device trees, working on binary .dtb
files.

fdtgrep can find nodes by name or compatible string. It can find properties
by name. Using a list of of nodes/properties/compatible strings to match,
fdtgrep creates either .dts text output containing just those matches, or
.dtb output. In the .dtb case, the output is a valid FDT which only includes
the selected nodes/properties. This is useful in resource-constrained systems
where a full FDT is too large to fit in available memory (e.g. U-Boot SPL).

fdtgrep also supports producing raw binary output, without the normal FDT
headers. This can be useful for hashing part of an FDT and making sure that
that part does not change, even if other parts do. This makes it possible to
detect an important change, while ignoring a change that is of no interest.

At its simplest fdtgrep can be used as follows;

   fdtgrep /holiday tests/grep.dtb

and it produces just that node (with a skeleton to hold it):

/ {
holiday {
compatible = ixtapa, mexico;
weather = sunny;
status = okay;
};
};

The binary form of this is:

   fdtgrep -n /holiday -O dtb tests/grep.dtb

which produces a valid DTB file with just the above nodes.

Various options are provided to search for properties, to ensure that
nodes/properties are not present, and to search for nodes by compatible
string.

Signed-off-by: Simon Glass s...@chromium.org
---
 .gitignore |1 +
 Makefile   |4 +
 Makefile.utils |7 +
 fdtgrep.c  |  775 
 tests/grep.dts |   23 ++
 tests/run_tests.sh |  348 +++-
 tests/tests.sh |1 +
 7 files changed, 1158 insertions(+), 1 deletions(-)
 create mode 100644 fdtgrep.c
 create mode 100644 tests/grep.dts

diff --git a/.gitignore b/.gitignore
index 545b899..9d3a550 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@ lex.yy.c
 /convert-dtsv0
 /version_gen.h
 /fdtget
+/fdtgrep
 /fdtput
 /patches
 /.pc
diff --git a/Makefile b/Makefile
index 1169e6c..96e0488 100644
--- a/Makefile
+++ b/Makefile
@@ -112,6 +112,7 @@ BIN += dtc
 BIN += fdtdump
 BIN += fdtget
 BIN += fdtput
+BIN += fdtgrep
 
 SCRIPTS = dtdiff
 
@@ -124,6 +125,7 @@ ifneq ($(DEPTARGETS),)
 -include $(FDTDUMP_OBJS:%.o=%.d)
 -include $(FDTGET_OBJS:%.o=%.d)
 -include $(FDTPUT_OBJS:%.o=%.d)
+-include $(FDTGREP_OBJS:%.o=%.d)
 endif
 
 
@@ -188,6 +190,7 @@ fdtget: $(FDTGET_OBJS) $(LIBFDT_archive)
 
 fdtput:$(FDTPUT_OBJS) $(LIBFDT_archive)
 
+fdtgrep:   $(FDTGREP_OBJS) $(LIBFDT_archive)
 
 #
 # Testsuite rules
@@ -198,6 +201,7 @@ TESTS_BIN += dtc
 TESTS_BIN += convert-dtsv0
 TESTS_BIN += fdtput
 TESTS_BIN += fdtget
+TESTS_BIN += fdtgrep
 
 include tests/Makefile.tests
 
diff --git a/Makefile.utils b/Makefile.utils
index 48ece49..f2a7001 100644
--- a/Makefile.utils
+++ b/Makefile.utils
@@ -22,3 +22,10 @@ FDTPUT_SRCS = \
util.c
 
 FDTPUT_OBJS = $(FDTPUT_SRCS:%.c=%.o)
+
+
+FDTGREP_SRCS = \
+   fdtgrep.c \
+   util.c
+
+FDTGREP_OBJS = $(FDTGREP_SRCS:%.c=%.o)
diff --git a/fdtgrep.c b/fdtgrep.c
new file mode 100644
index 000..bb08f12
--- /dev/null
+++ b/fdtgrep.c
@@ -0,0 +1,775 @@
+/*
+ * Copyright (c) 2013, Google Inc.
+ *
+ * Perform a grep of an FDT either displaying the source subset or producing
+ * a new .dtb subset which can be used as required.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include assert.h
+#include ctype.h
+#include getopt.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+
+#include libfdt.h
+#include libfdt_internal.h
+#include util.h
+
+/* Define DEBUG to get some debugging output on stderr */
+#ifdef DEBUG
+#define debug(a, b...) fprintf(stderr, a, ## b)
+#else
+#define debug(a, b...)
+#endif
+
+/* A linked list of values we are grepping for */
+struct value_node {
+   int type;   /* Types this value matches (FDT_IS... mask) */
+   int include;/* 1 to include matches, 0 to exclude */
+   const char *string; /* String to match */
+   struct value_node *next;/* Pointer to next node, or NULL */
+};
+
+/* Output formats we support */
+enum output_t {
+   OUT_DTS,/* Device tree source */
+   OUT_DTB

Re: [PATCH V7] kbuild: create a rule to run the pre-processor on *.dts files

[Simon Glass]

On Wed, Jan 2, 2013 at 10:43 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 From: Stephen Warren swar...@nvidia.com

 Create cmd_dtc_cpp to run the C pre-processor on *.dts file before
 passing them to dtc for final compilation. This allows the use of #define
 and #include within the .dts file.

 Signed-off-by: Stephen Warren swar...@nvidia.com

Acked-by: Simon Glass s...@chromium.org

 ---
 Grant, back in mid-November, you said you'd make a decision on this in
 the next couple of days, but I think this got overlooked.

 v7: Build *.dtb from *.dts not src/*.dts.
 v6: No change.
 v5:
 * Update Documentation/kbuild for the new command and rule.
 v4:
 * Use -x assembler-with-cpp so pre-defined macros are set up so that
   #included header files know to only use cpp syntax, not C syntax.
 * Define __DTS__ for similar reasons.
 * use $(CPP) not $(CC) -E, and use $(cpp_flags).
 * Save the pre-processed results so they can be easily inspected when
   debugging build issues.
 * The use of -x assembler-with-cpp causes cpp to recognize directives in
   column 1 only. Hence, there's no need to escape property names that
   begin with #. Hence, there's no need for separate skeleton.dtsi and
   skeleton.dtsip. Maintain a separate file extension and build rule so that
   CPP-usage is opt-in. In particular, when using CPP, #include must be used
   rather than /include/ so that dependencies work.
 v3: Pass -x c not -xc to cpp.
 v2: Place make %.dtb: %.dtsp rule into Makefile.lib.
 ---
  Documentation/kbuild/makefiles.txt |   23 +++
  scripts/Makefile.lib   |9 +
  2 files changed, 32 insertions(+)

 diff --git a/Documentation/kbuild/makefiles.txt 
 b/Documentation/kbuild/makefiles.txt
 index 14c3f4f..5198b74 100644
 --- a/Documentation/kbuild/makefiles.txt
 +++ b/Documentation/kbuild/makefiles.txt
 @@ -1186,6 +1186,29 @@ When kbuild executes, the following steps are followed 
 (roughly):
 clean-files += *.dtb
 DTC_FLAGS ?= -p 1024

 +dtc_cpp
 +   This is just like dtc as describe above, except that the C pre-
 +   processor is invoked upon the .dtsp file before compiling the result
 +   with dtc.
 +
 +   In order for build dependencies to work, all files compiled using
 +   dtc_cpp must use the C pre-processor's #include functionality and not
 +   dtc's /include/ functionality.
 +
 +   Using the C pre-processor allows use of #define to create named
 +   constants. In turn, the #defines will typically appear in a header
 +   file, which may be shared with regular C code. Since the dtc language
 +   represents a data structure rather than code in C syntax, similar
 +   restrictions are placed on a header file included by a device tree
 +   file as for a header file included by an assembly language file.
 +   In particular, the C pre-processor is passed -x assembler-with-cpp,
 +   which sets macro __ASSEMBLY__. __DTS__ is also set. These allow header
 +   files to restrict their content to that compatible with device tree
 +   source.
 +
 +   A central rule exists to create $(obj)/%.dtb from $(src)/%.dtsp;
 +   architecture Makefiles do no need to explicitly write out that rule.
 +
  --- 6.8 Custom kbuild commands

 When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand
 diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
 index bdf42fd..2c2a302 100644
 --- a/scripts/Makefile.lib
 +++ b/scripts/Makefile.lib
 @@ -269,6 +269,15 @@ cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 
 $(DTC_FLAGS) -d $(depfile
  $(obj)/%.dtb: $(src)/%.dts FORCE
 $(call if_changed_dep,dtc)

 +dtc-tmp = $(subst $(comma),_,$(dot-target).dts)
 +
 +quiet_cmd_dtc_cpp = DTC+CPP $@
 +cmd_dtc_cpp = $(CPP) $(cpp_flags) -D__DTS__ -x assembler-with-cpp -o 
 $(dtc-tmp) $ ; \
 +   $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $(dtc-tmp)
 +
 +$(obj)/%.dtb: $(src)/%.dtsp FORCE
 +   $(call if_changed_dep,dtc_cpp)
 +
  # Bzip2
  # ---

 --
 1.7.10.4

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v2] input: Extend matrix-keypad device tree binding

[Simon Glass]

Some matrix keypad drivers can support different numbers of rows and
columns. Add a generic binding for these.

Implementation note:

In order to implement this binding in the kernel, we will need to modify
matrix_keypad_() to look up the number of rows and cols in
the keymap. Perhaps this could be done by passing 0 for these parameters?
Many of the parameters can already be set to NULL. Ick.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Remove repeat rate parameters
- Update TI OMAP, tca8418 and lpc32xx bindings to use this one

 .../devicetree/bindings/input/lpc32xx-key.txt  |9 ++---
 .../devicetree/bindings/input/matrix-keymap.txt|8 
 .../devicetree/bindings/input/omap-keypad.txt  |   13 +
 .../devicetree/bindings/input/tca8418_keypad.txt   |6 --
 4 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/lpc32xx-key.txt 
b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
index 31afd50..bcf62f8 100644
--- a/Documentation/devicetree/bindings/input/lpc32xx-key.txt
+++ b/Documentation/devicetree/bindings/input/lpc32xx-key.txt
@@ -1,19 +1,22 @@
 NXP LPC32xx Key Scan Interface
 
+This binding is based on the matrix-keymap binding with the following
+changes:
+
 Required Properties:
 - compatible: Should be nxp,lpc3220-key
 - reg: Physical base address of the controller and length of memory mapped
   region.
 - interrupts: The interrupt number to the cpu.
-- keypad,num-rows: Number of rows and columns, e.g. 1: 1x1, 6: 6x6
-- keypad,num-columns: Must be equal to keypad,num-rows since LPC32xx only
-  supports square matrices
 - nxp,debounce-delay-ms: Debounce delay in ms
 - nxp,scan-delay-ms: Repeated scan period in ms
 - linux,keymap: the key-code to be reported when the key is pressed
   and released, see also
   Documentation/devicetree/bindings/input/matrix-keymap.txt
 
+Note: keypad,num-rows and keypad,num-columns are required, and must be equal
+since LPC32xx only supports square matrices
+
 Example:
 
key@4005 {
diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt 
b/Documentation/devicetree/bindings/input/matrix-keymap.txt
index 3cd8b98..c54919f 100644
--- a/Documentation/devicetree/bindings/input/matrix-keymap.txt
+++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt
@@ -9,6 +9,12 @@ Required properties:
row  24 | column  16 | key-code
 
 Optional properties:
+Properties for the number of rows and columns are optional because some
+drivers will use fixed values for these.
+- keypad,num-rows: Number of row lines connected to the keypad controller.
+- keypad,num-columns: Number of column lines connected to the keypad
+  controller.
+
 Some users of this binding might choose to specify secondary keymaps for
 cases where there is a modifier key such as a Fn key. Proposed names
 for said properties are linux,fn-keymap or with another descriptive
@@ -17,3 +23,5 @@ word for the modifier other from Fn.
 Example:
linux,keymap =  0x00030012
 0x0102003a ;
+   keypad,num-rows = 2;
+   keypad,num-columns = 8;
diff --git a/Documentation/devicetree/bindings/input/omap-keypad.txt 
b/Documentation/devicetree/bindings/input/omap-keypad.txt
index f2fa5e1..34ed1c6 100644
--- a/Documentation/devicetree/bindings/input/omap-keypad.txt
+++ b/Documentation/devicetree/bindings/input/omap-keypad.txt
@@ -6,19 +6,16 @@ A key can be placed at each intersection of a unique row and 
a unique column.
 The keypad controller can sense a key-press and key-release and report the
 event using a interrupt to the cpu.
 
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+keypad,num-rows and keypad,num-columns are required.
+
 Required SoC Specific Properties:
 - compatible: should be one of the following
- ti,omap4-keypad: For controllers compatible with omap4 keypad
   controller.
 
-Required Board Specific Properties, in addition to those specified by
-the shared matrix-keyboard bindings:
-- keypad,num-rows: Number of row lines connected to the keypad
-  controller.
-
-- keypad,num-columns: Number of column lines connected to the
-  keypad controller.
-
 Optional Properties specific to linux:
 - linux,keypad-no-autorepeat: do no enable autorepeat feature.
 
diff --git a/Documentation/devicetree/bindings/input/tca8418_keypad.txt 
b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
index 2a1538f..2551850 100644
--- a/Documentation/devicetree/bindings/input/tca8418_keypad.txt
+++ b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
@@ -1,8 +1,10 @@
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+keypad,num-rows and keypad,num-columns are required.
 
 Required properties:
 - compatible: ti,tca8418
 - reg: the I2C address
 - interrupts: IRQ line number, should trigger on falling edge
-- keypad,num-rows: The number of rows
-- keypad,num

Re: [PATCH 5/5] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Hi Grant,

On Wed, Dec 19, 2012 at 12:42 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
 On Wed, Dec 19, 2012 at 8:20 PM, Simon Glass s...@chromium.org wrote:
 On Wed, Dec 19, 2012 at 10:16 AM, Dmitry Torokhov
 dmitry.torok...@gmail.com wrote:

 On Wed, Dec 19, 2012 at 12:57:22PM +, Grant Likely wrote:
  On Fri, 14 Dec 2012 17:43:31 -0800, Dmitry Torokhov
  dmitry.torok...@gmail.com wrote:
   On Saturday, December 15, 2012 01:13:45 AM Grant Likely wrote:
 +Required properties:
 +- compatible: google,cros-ec-keyb
 +- google,key-rows: Number of keyboard rows (must be = 8)
 +- google,key-columns: Number of keyboard columns (must be = 13)
 +- google,repeat-delay-ms: Key repeat delay in milliseconds
 +- google,repeat-rate-ms: Key repeat rate in milliseconds
   
Hmmm, these should probably be in a common binding. Take a look at
the other input bindings and make a proposal for properties to add
to
matrix-keymap.txt.
  
   Actually these are not essentia for bringup and can be set from
   userspace,
   so I'd say simply drop them.
 
  Aren't they needed for a working keyboard? If so, I would really think
  they should be set correctly without userspace intervention.

 I am sorry if I was unclear, but I was actually talking about the last
 2: repeat-delay-ms and repeat-rate-ms. Input core has I believe sane
 defaults (250 msec delay, 33 cps autorepeat) and user can adjust if
 other rate is preferred.


 I seems like I should remove these two, then.

 It would be nice if we could keep these parameters so that the keyboard
 doesn't require user-space set up to work, but I understand and agree they
 are not essential. Regarding Grant's request to come up with a common
 binding, if I remove these then that is not needed, right?

 I have no problem keeping the properties, but it does look like
 something applicable to all users, not just this driver.

I dropped keyboard repeat from the common binding and resent. If that
goes in then I can try again later when Dmitry is on holiday :-), or I
can put it just in our own driver. I don't mind either way, so someone
should let me know which is best.


 g.

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH] RFC: input: Extend matrix-keypad device tree binding

[Simon Glass]

Some matrix keypad drivers can support different numbers of rows and
columns. Add a generic binding for these.

Also define properties for the repeat rate, to allow a sane baseline to
be set up for the driver.

Implementation note:

In order to implement this binding in the kernel, we will need to modify
matrix_keypad_() to look up the number of rows and cols in
the keymap. Perhaps this could be done by passing 0 for these parameters?
Many of the parameters can already be set to NULL. Ick.

For the key repeat feature, we need to set this after the input device
is registered. So we would need to add a matrix_keypad_setup_input() or
similar to be called by the driver after input_register_device(). I am
less keen on that idea, and less again on the alternative of perhaps
matrix_keypad_register_device() which does input_register_device() and
then sets up the key repeat. Thoughts?

Signed-off-by: Simon Glass s...@chromium.org
---
 .../devicetree/bindings/input/matrix-keymap.txt|   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt 
b/Documentation/devicetree/bindings/input/matrix-keymap.txt
index 3cd8b98..b953d27 100644
--- a/Documentation/devicetree/bindings/input/matrix-keymap.txt
+++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt
@@ -9,6 +9,16 @@ Required properties:
row  24 | column  16 | key-code
 
 Optional properties:
+Properties for the number of rows and columns are optional because some
+drivers will use fixed values for these.
+- keypad,num-rows: Number of row lines connected to the keypad controller.
+- keypad,num-columns: Number of column lines connected to the keypad
+  controller.
+- keypad,repeat-delay-ms: Number of milliseconds of delay before the first
+  keyboard repeat when a key is held down.
+- keypad,repeat-rate-ms: Number of milliseconds between each subsequent
+  keyboard repeat when a key is held down.
+
 Some users of this binding might choose to specify secondary keymaps for
 cases where there is a modifier key such as a Fn key. Proposed names
 for said properties are linux,fn-keymap or with another descriptive
@@ -17,3 +27,7 @@ word for the modifier other from Fn.
 Example:
linux,keymap =  0x00030012
 0x0102003a ;
+   keypad,num-rows = 2;
+   keypad,num-columns = 8;
+   keypad,repeat-delay-ms = 600;
+   keypad,repeat-rate-ms = 60;
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH] RFC: input: Extend matrix-keypad device tree binding

[Simon Glass]

Hi Dmitry,

On Thu, Dec 20, 2012 at 1:13 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 Hi Simon,

 On Thu, Dec 20, 2012 at 12:23:58PM -0800, Simon Glass wrote:

 For the key repeat feature, we need to set this after the input device
 is registered. So we would need to add a matrix_keypad_setup_input() or
 similar to be called by the driver after input_register_device(). I am
 less keen on that idea, and less again on the alternative of perhaps
 matrix_keypad_register_device() which does input_register_device() and
 then sets up the key repeat. Thoughts?

 No, we already have default rate and delay. Unless you can prove that
 random firmware writer's idea of appropriate delay and rate is better
 then current default - for everyone - and then can successfully argue
 that that obviously best delay/rate combo should not replace the current
 one but stay only in DT bindings, let's keep relying on users adjusting
 their own preferences from respective desktop environments/console/etc.

Seems reasonable. My only comment on this is that the device tree
comes from kernel, not firmware. This lets us configure an embedded
system easily (where the user may not have access to repeat rate
preferences).

Grant are you OK with me just dropping the repeat settings, and
keeping the other two? If so I will respin the patch.

Regards,
Simon


 Thanks.

 --
 Dmitry
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 5/5] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

On Wed, Dec 19, 2012 at 10:16 AM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 On Wed, Dec 19, 2012 at 12:57:22PM +, Grant Likely wrote:
 On Fri, 14 Dec 2012 17:43:31 -0800, Dmitry Torokhov 
 dmitry.torok...@gmail.com wrote:
  On Saturday, December 15, 2012 01:13:45 AM Grant Likely wrote:
   On Wed, 12 Dec 2012 13:33:48 -0800, Simon Glass s...@chromium.org 
   wrote:
Use the key-matrix layer to interpret key scan information from the EC
and inject input based on the FDT-supplied key map. This driver 
registers
itself with the ChromeOS EC driver to perform communications.
   
Additional FDT bindings are provided to specify rows/columns and the
auto-repeat information.
   
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
   
 .../devicetree/bindings/input/cros-ec-keyb.txt |   77 
 drivers/input/keyboard/Kconfig |   10 +
 drivers/input/keyboard/Makefile|1 +
 drivers/input/keyboard/cros_ec_keyb.c  |  413
  4 files changed, 501 insertions(+), 0 
deletions(-)
 create mode 100644
 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
   
diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt new file 
mode
100644
index 000..67f51d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,77 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented 
on
+a separate EC (Embedded Controller) device. It provides a message for
reading +key scans from the EC. These are then converted into keycodes
for processing +by the kernel.
+
+Required properties:
+- compatible: google,cros-ec-keyb
+- google,key-rows: Number of keyboard rows (must be = 8)
+- google,key-columns: Number of keyboard columns (must be = 13)
+- google,repeat-delay-ms: Key repeat delay in milliseconds
+- google,repeat-rate-ms: Key repeat rate in milliseconds
  
   Hmmm, these should probably be in a common binding. Take a look at
   the other input bindings and make a proposal for properties to add to
   matrix-keymap.txt.
 
  Actually these are not essentia for bringup and can be set from userspace,
  so I'd say simply drop them.

 Aren't they needed for a working keyboard? If so, I would really think
 they should be set correctly without userspace intervention.

 I am sorry if I was unclear, but I was actually talking about the last
 2: repeat-delay-ms and repeat-rate-ms. Input core has I believe sane
 defaults (250 msec delay, 33 cps autorepeat) and user can adjust if
 other rate is preferred.

(resending due to mailing problem)

I seems like I should remove these two, then.

It would be nice if we could keep these parameters so that the
keyboard doesn't require user-space set up to work, but I understand
and agree they are not essential. Regarding Grant's request to come up
with a common binding, if I remove these then that is not needed,
right?

Regards,
Simon


 Thanks.

 --
 Dmitry
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 1/2] i2c-core: Add gpio based bus arbitration implementation

[Simon Glass]

On Wed, Dec 19, 2012 at 9:14 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
 On Wed, Dec 19, 2012 at 12:32:01PM +, Grant Likely wrote:

 I'm not convinced on the design of this protocol. It won't scale beyond
 2 bus masters and it seems very specific to the design of a specific
 piece of hardware. I don't think it is mature enough to bake into the

 I ought to point out that the original patch would've baked this into
 the Samsung I2C driver but I asked for it to be split out as it's
 nothing to do with the controller really and I'm sure I've seen it
 before.

Grant your idea looks nice to me. I only worry if we should wait until
we have a second user before going so far with it. But it is certainly
a nice general solution.

The scaling beyond two bus masters would require the code to be
changed to check more input lines from other masters. Best avoided for
now I think until we have a use for it.

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 0/5] Add ChromeOS Embedded Controller support

[Simon Glass]

(get_maintainer.pl has produced an enormous list - I hope you are all
interested.)

The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
connected on a bus (such as I2C, SPI, LPC) to the AP. A separate interrupt
line is used to indicate when the EC needs service.

Functions performed by the EC vary by platform, but typically include
battery charging, keyboard scanning and power sequencing.

This series includes support for the EC message protocol, and implements
a matrix keyboard handler for Linux using the protocol. The EC performs
key scanning and passes scan data in response to AP requests. This is
used on the Samsung ARM Chromebook. No driver is available for LPC at
present.

This series can in principle operate on any hardware, but for it to actually
work on the Samsung ARM Chromebook, it needs patches which are currently in
progress to mainline: Exynos FDT interrupt support and I2C bus arbitration.

The driver is device-tree-enabled and a suitable binding is included in
this series. Example device tree nodes are included in the examples,
but no device tree patch for exynos5250-snow is provided at this stage, since
we must wait for the above-mentioned patches to land to avoid errors from
dtc. This can be added with a follow-on patch when that work is complete.


Simon Glass (5):
  mfd: Add ChromeOS EC messages header
  mfd: Add ChromeOS EC implementation
  mfd: Add ChromeOS EC I2C driver
  mfd: Add ChromeOS EC SPI driver
  Input: Add ChromeOS EC keyboard driver

 .../devicetree/bindings/input/cros-ec-keyb.txt |   77 ++
 Documentation/devicetree/bindings/mfd/cros-ec.txt  |   56 +
 drivers/input/keyboard/Kconfig |   10 +
 drivers/input/keyboard/Makefile|1 +
 drivers/input/keyboard/cros_ec_keyb.c  |  413 ++
 drivers/mfd/Kconfig|   28 +
 drivers/mfd/Makefile   |3 +
 drivers/mfd/cros_ec.c  |  219 
 drivers/mfd/cros_ec_i2c.c  |  262 
 drivers/mfd/cros_ec_spi.c  |  412 ++
 include/linux/mfd/cros_ec.h|  190 +++
 include/linux/mfd/cros_ec_commands.h   | 1369 
 12 files changed, 3040 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
 create mode 100644 drivers/mfd/cros_ec.c
 create mode 100644 drivers/mfd/cros_ec_i2c.c
 create mode 100644 drivers/mfd/cros_ec_spi.c
 create mode 100644 include/linux/mfd/cros_ec.h
 create mode 100644 include/linux/mfd/cros_ec_commands.h

-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 2/5] mfd: Add ChromeOS EC implementation

[Simon Glass]

This is the base EC implementation, which provides a high level
interface to the EC for use by the rest of the kernel. The actual
communcations is dealt with by a separate protocol driver which
registers itself with this interface.

Interrupts are passed on through a notifier. The driver supports
resume notification also, in case drivers wish to perform some
action there.

A simple message structure is used to pass messages to the
protocol driver.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Che-Liang Chiou clch...@chromium.org
Signed-off-by: Jonathan Kliegman kli...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Olof Johansson ol...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
 Documentation/devicetree/bindings/mfd/cros-ec.txt |   56 ++
 drivers/mfd/Kconfig   |8 +
 drivers/mfd/Makefile  |1 +
 drivers/mfd/cros_ec.c |  219 +
 include/linux/mfd/cros_ec.h   |  190 ++
 5 files changed, 474 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/cros-ec.txt
 create mode 100644 drivers/mfd/cros_ec.c
 create mode 100644 include/linux/mfd/cros_ec.h

diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt 
b/Documentation/devicetree/bindings/mfd/cros-ec.txt
new file mode 100644
index 000..e0e59c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -0,0 +1,56 @@
+ChromeOS Embedded Controller
+
+Google's ChromeOS EC is a Cortex-M device which talks to the AP and
+implements various function such as keyboard and battery charging.
+
+The EC can be connect through various means (I2C, SPI, LPC) and the
+compatible string used depends on the inteface. Each connection method has
+its own driver which connects to the top level interface-agnostic EC driver.
+Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
+the top-level driver.
+
+Required properties (I2C):
+- compatible: google,cros-ec-i2c
+- reg: I2C slave address
+
+Required properties (SPI):
+- compatible: google,cros-ec-spi
+- reg: SPI chip select
+
+Required properties (LPC):
+- compatible: google,cros-ec-lpc
+- reg: List of (IO address, size) pairs defining the interface uses
+
+
+Example for I2C:
+
+i2c@12CA {
+   cros-ec@1e {
+   reg = 0x1e;
+   compatible = google,cros-ec-i2c;
+   interrupts = 14 0;
+   interrupt-parent = wakeup_eint;
+   wakeup-source;
+   };
+
+
+Example for SPI:
+
+spi@131b {
+   ec@0 {
+   compatible = google,cros-ec-spi;
+   reg = 0x0;
+   interrupts = 14 0;
+   interrupt-parent = wakeup_eint;
+   wakeup-source;
+   spi-max-frequency = 500;
+   controller-data {
+   cs-gpio = gpf0 3 4 3 0;
+   samsung,spi-cs;
+   samsung,spi-feedback-delay = 2;
+   };
+   };
+};
+
+
+Example for LPC is not supplied as it is not yet implemented.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 09d43a9..6983eb4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -21,6 +21,14 @@ config MFD_88PM860X
  select individual components like voltage regulators, RTC and
  battery-charger under the corresponding menus.
 
+config MFD_CROS_EC
+   bool Support ChromeOS Embedded Controller
+   help
+ If you say yes here you get support for the ChromeOS Embedded
+ Controller (EC) providing keyboard, battery and power services.
+ You also ned to enable the driver for the bus you are using. The
+ protocol for talking to the EC is defined by the bus driver.
+
 config MFD_88PM800
tristate Support Marvell 88PM800
depends on I2C=y  GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index baab62e..5a9c9f6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM800)   += 88pm800.o 88pm80x.o
 obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
 obj-$(CONFIG_MFD_SM501)+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
+obj-$(CONFIG_MFD_CROS_EC)  += cros_ec.o
 
 rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o
 obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
new file mode 100644
index 000..a3651cb
--- /dev/null
+++ b/drivers/mfd/cros_ec.c
@@ -0,0 +1,219 @@
+/*
+ * ChromeOS EC multi-function device
+ *
+ * Copyright (C) 2012 Google, Inc
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program

[PATCH 5/5] Input: Add ChromeOS EC keyboard driver

[Simon Glass]

Use the key-matrix layer to interpret key scan information from the EC
and inject input based on the FDT-supplied key map. This driver registers
itself with the ChromeOS EC driver to perform communications.

Additional FDT bindings are provided to specify rows/columns and the
auto-repeat information.

Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Luigi Semenzato semenz...@chromium.org
Signed-off-by: Vincent Palatin vpala...@chromium.org
---
 .../devicetree/bindings/input/cros-ec-keyb.txt |   77 
 drivers/input/keyboard/Kconfig |   10 +
 drivers/input/keyboard/Makefile|1 +
 drivers/input/keyboard/cros_ec_keyb.c  |  413 
 4 files changed, 501 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/cros-ec-keyb.txt
 create mode 100644 drivers/input/keyboard/cros_ec_keyb.c

diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt 
b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
new file mode 100644
index 000..67f51d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
@@ -0,0 +1,77 @@
+ChromeOS EC Keyboard
+
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
+
+Required properties:
+- compatible: google,cros-ec-keyb
+- google,key-rows: Number of keyboard rows (must be = 8)
+- google,key-columns: Number of keyboard columns (must be = 13)
+- google,repeat-delay-ms: Key repeat delay in milliseconds
+- google,repeat-rate-ms: Key repeat rate in milliseconds
+- linux.keymap: Key map as for matrix-keypad.txt
+
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
+
+
+Example:
+
+cros-ec-keyb {
+   compatible = google,cros-ec-keyb;
+   google,key-rows = 8;
+   google,key-columns = 13;
+   google,repeat-delay-ms = 600;
+   google,repeat-rate-ms = 60;
+   google,needs-ghost-filter;
+   /*
+* Keymap entries take the form of 0xRRCC where
+* RR=Row CC=Column =Key Code
+* The values below are for a US keyboard layout and
+* are taken from the Linux driver. Note that the
+* 102ND key is not used for US keyboards.
+*/
+   linux,keymap = 
+   /* CAPSLCK F1 B  F10 */
+   0x0001003a 0x0002003b 0x00030030 0x00040044
+   /* N   =  R_ALT  ESC */
+   0x00060031 0x0008000d 0x000a0064 0x01010001
+   /* F4  G  F7 H   */
+   0x0102003e 0x01030022 0x01040041 0x01060023
+   /* '   F9 BKSPACEL_CTRL  */
+   0x01080028 0x01090043 0x010b000e 0x021d
+   /* TAB F3 T  F6  */
+   0x0201000f 0x0202003d 0x02030014 0x02040040
+   /* ]   Y  102ND  [   */
+   0x0205001b 0x02060015 0x02070056 0x0208001a
+   /* F8  GRAVE  F2 5   */
+   0x02090042 0x03010029 0x0302003c 0x03030006
+   /* F5  6  -  \   */
+   0x0304003f 0x03060007 0x0308000c 0x030b002b
+   /* R_CTRL  A  D  F   */
+   0x0461 0x0401001e 0x04020020 0x04030021
+   /* S   K  J  ;   */
+   0x0404001f 0x04050025 0x04060024 0x04080027
+   /* L   ENTER  Z  C   */
+   0x04090026 0x040b001c 0x0501002c 0x0502002e
+   /* V   X  ,  M   */
+   0x0503002f 0x0504002d 0x05050033 0x05060032
+   /* L_SHIFT /  .  SPACE   */
+   0x0507002a 0x05080035 0x05090034 0x050B0039
+   /* 1   3  4  2   */
+   0x06010002 0x06020004 0x06030005 0x06040003
+   /* 8   7  0  9   */
+   0x06050009 0x06060008 0x0608000b 0x0609000a
+   /* L_ALT   DOWN   RIGHT  Q   */
+   0x060a0038 0x060b006c 0x060c006a 0x07010010
+   /* E   R  W  I   */
+   0x07020012 0x07030013 0x07040011 0x07050017
+   /* U   R_SHIFTP  O   */
+   0x07060016 0x07070036 0x07080019 0x07090018
+   /* UP  LEFT*/
+   0x070b0067 0x070c0069;
+};
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 7ccd652..eb16434 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -617,4 +617,14

Re: RFC: New release for DTC?

[Simon Glass]

Hi Jon,

On Tue, Dec 11, 2012 at 6:55 AM, Jon Loeliger j...@jdl.com wrote:
  
   This has been a bit of a perrenial problem.  dtc development has been
   sufficiently gradual that there haven't been many obvious points for
   making new releases.  dtc developers (i.e. Jon and my, mostly) don't
   feel much pain from the lack of releases, since the git snapshots
   generally work well (thanks to limited scope and a good testsuite).
  
   I wonder if we should move to a model of just making a release every 3
   or 6 months from whatever happens to be in the tree at the time
   (barring obvious known breakage, of course).
 
  yes please.  even just a version that uses datestamps would be fine.
  -mike
 
  Fine by me.

 So is this happening? I agree a regular release would be useful, and I
 think it has been about 18 months since the last release.

 I'll apply a couple 3 outstanding patches (from Kim Phillips)
 and get around to tagging a new release.  If you, or anyone else
 have patches or functionality you want in this release, please
 post those patches now.

OK thanks. I don't have any new patches at present.


 jdl

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: RFC: New release for DTC?

[Simon Glass]

Hi,

On Sat, Nov 17, 2012 at 4:00 PM, Grant Likely grant.lik...@secretlab.ca wrote:
 On Sat, 17 Nov 2012 12:50:07 -0500, Mike Frysinger vap...@gentoo.org wrote:
 On Thursday 23 August 2012 21:36:25 David Gibson wrote:
  On Thu, Aug 23, 2012 at 08:15:39PM +0200, Yann E. MORIN wrote:
   Following advice from Jon Loeliger, I would suggest that a new release
   of DTC be tagged and packaged.
  
   It is important for some projects to rely on a released version, rather
   than use a random cset from the repository. Comes to mind, the automated
   build-systems, such as buildroot.
  
   Of course, I can help, if need be! ;-)
  
   Are there any others who think that a release would make sense?
 
  This has been a bit of a perrenial problem.  dtc development has been
  sufficiently gradual that there haven't been many obvious points for
  making new releases.  dtc developers (i.e. Jon and my, mostly) don't
  feel much pain from the lack of releases, since the git snapshots
  generally work well (thanks to limited scope and a good testsuite).
 
  I wonder if we should move to a model of just making a release every 3
  or 6 months from whatever happens to be in the tree at the time
  (barring obvious known breakage, of course).

 yes please.  even just a version that uses datestamps would be fine.
 -mike

 Fine by me.

So is this happening? I agree a regular release would be useful, and I
think it has been about 18 months since the last release.

Regards,
Simon


 g.

 ___
 devicetree-discuss mailing list
 devicetree-discuss@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v2 15/23] fdt: edid: Enable fdt_add_edid() function when CONFIG_LCD defined

[Simon Glass]

From: Tom Wai-Hong Tam waih...@chromium.org

This function can be used for LCDs as well as monitors.

Signed-off-by: Tom Wai-Hong Tam waih...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None

 common/fdt_support.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 963ea90..6b9fa05 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1315,7 +1315,7 @@ int fdt_set_status_by_alias(void *fdt, const char* alias,
return fdt_set_node_status(fdt, offset, status, error_code);
 }
 
-#if defined(CONFIG_VIDEO)
+#if defined(CONFIG_VIDEO) || defined(CONFIG_LCD)
 int fdt_add_edid(void *blob, const char *compat, unsigned char *edid_buf)
 {
int noff;
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Device tree node to major/minor?

[Simon Glass]

Hi Grant,

On Wed, Nov 21, 2012 at 7:47 AM, Grant Likely grant.lik...@secretlab.ca wrote:
 On Tue, 20 Nov 2012 15:48:24 -0800, Simon Glass s...@chromium.org wrote:
 Hi Grant,

 On Tue, Nov 20, 2012 at 2:32 PM, Grant Likely grant.lik...@secretlab.ca 
 wrote:
  On Tue, Nov 20, 2012 at 10:23 PM, Simon Glass s...@chromium.org wrote:
  Hi,
 
  I hope this is a stupid question with an easy answer, but I cannot find 
  it.
 
  I have a device tree node for an mmc block device and I want to use
  that block device from another driver. I have a phandle which lets me
  get the node of the mmc device, but I am not sure how to convert that
  into a block_device. In order to do so, I think I need a major/minor
  number. Of course the phandle might in fact point to a SCSI driver and
  I want that to work correctly also.
 
  I imagine I might be able to search through the wonders of sysfs in
  user space, but is there a better way?
 
  Do you /want/ to do it from userspace? What is your use case? Mounting
  the rootfs?

 The use case is storing some raw data on a block device from within a
 driver in the kernel. It is used to keep track of the verified boot
 state.

 
  Regardless, userspace can monitor the uevents when devices are added
  (that's what udev does) and watch for the full path of the node you
  want in the uevent attribute. Then you can look for the child device
  with the block major/minor numbers in it.

 So is there a way to do this entirely in the kernel ex post? It might
 need to happen during kernel boot, before user space.

 Yes, it is certainly doable within the kernel. First, you'll need to use
 a notifier to get called back whenever a new device is created. Then
 you'll need to look at the dev-of_node(-full_name) to see if it is the
 node you actually want. You might need/want to resolve it from an alias
 or something, but I presume you already have a way to find the
 device_node before seaching for a struct device.

OK thank you. Was hoping to find a simple way to find a block device
from a device tree node (yes I know the right one) but I suppose in
general this is impossible, since nodes may create more than one
device, and each has its own data structures leading to the block
device.

So it seems like a notifier is the best way. Thanks for looking at this Grant.

Regards,
Simon


 g.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Device tree node to major/minor?

[Simon Glass]

Hi,

I hope this is a stupid question with an easy answer, but I cannot find it.

I have a device tree node for an mmc block device and I want to use
that block device from another driver. I have a phandle which lets me
get the node of the mmc device, but I am not sure how to convert that
into a block_device. In order to do so, I think I need a major/minor
number. Of course the phandle might in fact point to a SCSI driver and
I want that to work correctly also.

I imagine I might be able to search through the wonders of sysfs in
user space, but is there a better way?

Thanks,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Device tree node to major/minor?

[Simon Glass]

Hi Grant,

On Tue, Nov 20, 2012 at 2:32 PM, Grant Likely grant.lik...@secretlab.ca wrote:
 On Tue, Nov 20, 2012 at 10:23 PM, Simon Glass s...@chromium.org wrote:
 Hi,

 I hope this is a stupid question with an easy answer, but I cannot find it.

 I have a device tree node for an mmc block device and I want to use
 that block device from another driver. I have a phandle which lets me
 get the node of the mmc device, but I am not sure how to convert that
 into a block_device. In order to do so, I think I need a major/minor
 number. Of course the phandle might in fact point to a SCSI driver and
 I want that to work correctly also.

 I imagine I might be able to search through the wonders of sysfs in
 user space, but is there a better way?

 Do you /want/ to do it from userspace? What is your use case? Mounting
 the rootfs?

The use case is storing some raw data on a block device from within a
driver in the kernel. It is used to keep track of the verified boot
state.


 Regardless, userspace can monitor the uevents when devices are added
 (that's what udev does) and watch for the full path of the node you
 want in the uevent attribute. Then you can look for the child device
 with the block major/minor numbers in it.

So is there a way to do this entirely in the kernel ex post? It might
need to happen during kernel boot, before user space.


 g.

Thanks,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [U-Boot] [PATCH 0/14] fdt: Add various device tree utilities and features

[Simon Glass]

Hi Jerry,

On Sat, Nov 17, 2012 at 5:35 PM, Jerry Van Baren gvb.ub...@gmail.com wrote:
 Dear Simon,

 Sorry for being so late on this (the patches were submitted before the
 merge window closed).  I've applied the patches to the next branch in
 the u-boot-fdt repo.
   http://git.denx.de/?p=u-boot/u-boot-fdt.git;a=shortlog;h=refs/heads/next

 I'm assuming these are still valid (Simon) and eligible to be applied to
 the v2013.01 u-boot release (Tom).  If so, I'll submit a pull request.

Yes still valid thank you. The only question is around the GPIO patch
(http://patchwork.ozlabs.org/patch/194340/) since as Stephen pointed
out there is discussion on the kernel list of whether to keep the
polarity bit. I suppose we can always address that later if they
decide to replace it with something else.


 On 10/25/2012 10:30 PM, Simon Glass wrote:
 This series contains a number of features related to CONFIG_OF_CONTROL,
 such as:

 - reading fdt values
 - reading configuration from the fdt
 - allowing the fdt to specify a boot command

 [snip]

  README |   11 +
  common/cmd_bootm.c |   11 +
  common/image.c |  127 
 
  common/main.c  |  102 +-
  include/fdtdec.h   |  121 +
  include/image.h|1 +
  lib/fdtdec.c   |  107 +---
  7 files changed, 472 insertions(+), 8 deletions(-)

 Again, my apologies,

No problem, we all have plenty to do!

 gvb


Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [U-Boot] [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

Hi Stephen,

On Wed, Oct 31, 2012 at 9:50 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 10/31/2012 05:59 PM, Simon Glass wrote:
 Hi,

 On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach d...@lynxeye.de wrote:
 Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
 From: Sean Paul seanp...@chromium.org

 Add get and set gpio functions to fdtdec that take into account the
 polarity field in fdtdec_gpio_state.flags.

 In another thread Stephen Warren and I came to the conclusion that we
 most likely should remove this polarity flag from the GPIO bindings.

 Currently it is only for the USB VBUS GPIO which should move over to
 regulators once they land in U-Boot. Do you have any other applications
 for this flag, so we might reconsider removing it?


 Well, any time you have a flag which is inverted in meaning, it can be
 useful. We have several switches on the board which can be active high
 or low, and polarity is used for that.

 In fact, it would be nice IMO to be able to specify input/output as
 well. I know the exynos bindings do this. There is a noddy function
 called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
 out. I discussed with Stephen some time ago how GPIOs should be
 SOC-specific and it should be possible to set up a GPIO with a single
 call, as Linux does. The more information there is in the binding, the
 more it can do automatically.

 Does the Tegra Linux GPIO binding still have a polarity?

 Yes it does, although in practice it can't be used (and hence should
 really be removed), since not all GPIO bindings have such a flag, so
 there is always a need for a separate property to indicate the polarity
 (c.f. fixed-regulator with GPIO control bindings for example).


I've had a bit of time to look into this. I see that the regulator
framework in the kernel seems to be used for various control purposes,
and provides useful polarity stuff. I was rather hoping that GPIOs
could be a bit more high level in U-Boot, with information about:

- input/output
- drive strength
- polarity
- pull up/down

In fact most of these are actually supported in most kernel bindings,
but of course it is binding-specific. Would it be useful to ask for a
polarity setting in the GPIO. When it is not available, the polarity
would then always be normal.

This might avoid moving polarity and input/output selecting down into
each client of the gpio, which seems undesirable in general.

Should we consider a second level of indirection for GPIOs to support
these non-binding features? It seems a bit complicated though.

However, if it is too late to do this, or not desirable for some
reason, then we should just drop this patch.

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [U-Boot] [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

Hi Stephen,

On Thu, Nov 15, 2012 at 3:46 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 11/15/2012 04:31 PM, Simon Glass wrote:
 Hi Stephen,

 On Wed, Oct 31, 2012 at 9:50 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 10/31/2012 05:59 PM, Simon Glass wrote:
 Hi,

 On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach d...@lynxeye.de wrote:
 Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
 From: Sean Paul seanp...@chromium.org

 Add get and set gpio functions to fdtdec that take into account the
 polarity field in fdtdec_gpio_state.flags.

 In another thread Stephen Warren and I came to the conclusion that we
 most likely should remove this polarity flag from the GPIO bindings.

 Currently it is only for the USB VBUS GPIO which should move over to
 regulators once they land in U-Boot. Do you have any other applications
 for this flag, so we might reconsider removing it?


 Well, any time you have a flag which is inverted in meaning, it can be
 useful. We have several switches on the board which can be active high
 or low, and polarity is used for that.

 In fact, it would be nice IMO to be able to specify input/output as
 well. I know the exynos bindings do this. There is a noddy function
 called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
 out. I discussed with Stephen some time ago how GPIOs should be
 SOC-specific and it should be possible to set up a GPIO with a single
 call, as Linux does. The more information there is in the binding, the
 more it can do automatically.

 Does the Tegra Linux GPIO binding still have a polarity?

 Yes it does, although in practice it can't be used (and hence should
 really be removed), since not all GPIO bindings have such a flag, so
 there is always a need for a separate property to indicate the polarity
 (c.f. fixed-regulator with GPIO control bindings for example).


 I've had a bit of time to look into this. I see that the regulator
 framework in the kernel seems to be used for various control purposes,
 and provides useful polarity stuff. I was rather hoping that GPIOs
 could be a bit more high level in U-Boot, with information about:

 - input/output
 - drive strength
 - polarity
 - pull up/down

 In fact most of these are actually supported in most kernel bindings,
 but of course it is binding-specific. Would it be useful to ask for a
 polarity setting in the GPIO. When it is not available, the polarity
 would then always be normal.

 This might avoid moving polarity and input/output selecting down into
 each client of the gpio, which seems undesirable in general.

 Should we consider a second level of indirection for GPIOs to support
 these non-binding features? It seems a bit complicated though.

 However, if it is too late to do this, or not desirable for some
 reason, then we should just drop this patch.

 The issue may not be bad enough we have to drop flag usage. It's also
 being discussed at:

 http://www.spinics.net/lists/arm-kernel/msg206299.html

 I'd recommend seeing how that pans out before making a decision whether
 to start/keep using flags or not.


Thanks, will await news.

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 10/20] x86: fdt: Create basic .dtsi file for coreboot

[Simon Glass]

This contains just the minimum information for a coreboot-based board.

Signed-off-by: Stefan Reinauer reina...@chromium.org
Signed-off-by: Gabe Black gabebl...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
 arch/x86/dts/coreboot.dtsi |   16 
 arch/x86/dts/skeleton.dtsi |   13 +
 2 files changed, 29 insertions(+), 0 deletions(-)
 create mode 100644 arch/x86/dts/coreboot.dtsi
 create mode 100644 arch/x86/dts/skeleton.dtsi

diff --git a/arch/x86/dts/coreboot.dtsi b/arch/x86/dts/coreboot.dtsi
new file mode 100644
index 000..4862a59
--- /dev/null
+++ b/arch/x86/dts/coreboot.dtsi
@@ -0,0 +1,16 @@
+/include/ skeleton.dtsi
+
+/ {
+   aliases {
+   console = /serial;
+   };
+
+   serial {
+   compatible = ns16550;
+   reg-shift = 1;
+   io-mapped = 1;
+   multiplier = 1;
+   baudrate = 115200;
+   status = disabled;
+   };
+};
diff --git a/arch/x86/dts/skeleton.dtsi b/arch/x86/dts/skeleton.dtsi
new file mode 100644
index 000..b41d241
--- /dev/null
+++ b/arch/x86/dts/skeleton.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree; the bare minimum needed to boot; just include and
+ * add a compatible value.  The bootloader will typically populate the memory
+ * node.
+ */
+
+/ {
+   #address-cells = 1;
+   #size-cells = 1;
+   chosen { };
+   aliases { };
+   memory { device_type = memory; reg = 0 0; };
+};
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 12/17] fdt: edid: Enable fdt_add_edid() function when CONFIG_LCD defined

[Simon Glass]

From: Tom Wai-Hong Tam waih...@chromium.org

This function can be used for LCDs as well as monitors.

Signed-off-by: Tom Wai-Hong Tam waih...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
 common/fdt_support.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 963ea90..6b9fa05 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1315,7 +1315,7 @@ int fdt_set_status_by_alias(void *fdt, const char* alias,
return fdt_set_node_status(fdt, offset, status, error_code);
 }
 
-#if defined(CONFIG_VIDEO)
+#if defined(CONFIG_VIDEO) || defined(CONFIG_LCD)
 int fdt_add_edid(void *blob, const char *compat, unsigned char *edid_buf)
 {
int noff;
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [PATCH 05/14] fdt: Export fdtdec_find_alias_node() function

[Simon Glass]

Hi David,

On Thu, Oct 25, 2012 at 9:24 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
 On Thu, Oct 25, 2012 at 07:31:02PM -0700, Simon Glass wrote:
 This function is useful outside fdtdec, so export it.

 Hrm.  fdt_path_offset() in libfdt itself will already look up aliases
 if given a path that doesn't start with '/'.  So it's not clear why
 you need this function at all.

Ahh, well I won't be needing that patch, then. I will submit one to
remove this function. Thank you.

Regards,
Simon


 --
 David Gibson| I'll have my music baroque, and my code
 david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
 | _way_ _around_!
 http://www.ozlabs.org/~dgibson
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: [U-Boot] [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

Hi,

On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach d...@lynxeye.de wrote:
 Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
 From: Sean Paul seanp...@chromium.org

 Add get and set gpio functions to fdtdec that take into account the
 polarity field in fdtdec_gpio_state.flags.

 In another thread Stephen Warren and I came to the conclusion that we
 most likely should remove this polarity flag from the GPIO bindings.

 Currently it is only for the USB VBUS GPIO which should move over to
 regulators once they land in U-Boot. Do you have any other applications
 for this flag, so we might reconsider removing it?


Well, any time you have a flag which is inverted in meaning, it can be
useful. We have several switches on the board which can be active high
or low, and polarity is used for that.

In fact, it would be nice IMO to be able to specify input/output as
well. I know the exynos bindings do this. There is a noddy function
called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
out. I discussed with Stephen some time ago how GPIOs should be
SOC-specific and it should be possible to set up a GPIO with a single
call, as Linux does. The more information there is in the binding, the
more it can do automatically.

Does the Tegra Linux GPIO binding still have a polarity?

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v2 05/14] fdt: Remove fdtdec_find_alias_node() function

[Simon Glass]

This function is not needed, since fdt_path_offset() performs the same
service. Remove it.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Remove fdtdec_find_alias_node() function

 lib/fdtdec.c |   24 +---
 1 files changed, 1 insertions(+), 23 deletions(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 32f03cc..4d6d392 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -52,28 +52,6 @@ const char *fdtdec_get_compatible(enum fdt_compat_id id)
return compat_names[id];
 }
 
-/**
- * Look in the FDT for an alias with the given name and return its node.
- *
- * @param blob FDT blob
- * @param name alias name to look up
- * @return node offset if found, or an error code  0 otherwise
- */
-static int find_alias_node(const void *blob, const char *name)
-{
-   const char *path;
-   int alias_node;
-
-   debug(find_alias_node: %s\n, name);
-   alias_node = fdt_path_offset(blob, /aliases);
-   if (alias_node  0)
-   return alias_node;
-   path = fdt_getprop(blob, alias_node, name, NULL);
-   if (!path)
-   return -FDT_ERR_NOTFOUND;
-   return fdt_path_offset(blob, path);
-}
-
 fdt_addr_t fdtdec_get_addr(const void *blob, int node,
const char *prop_name)
 {
@@ -171,7 +149,7 @@ int fdtdec_next_alias(const void *blob, const char *name,
/* snprintf() is not available */
assert(strlen(name)  MAX_STR_LEN);
sprintf(str, %.*s%d, MAX_STR_LEN, name, *upto);
-   node = find_alias_node(blob, str);
+   node = fdt_path_offset(blob, str);
if (node  0)
return node;
err = fdt_node_check_compatible(blob, node, compat_names[id]);
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 0/14] fdt: Add various device tree utilities and features

[Simon Glass]

This series contains a number of features related to CONFIG_OF_CONTROL,
such as:

- reading fdt values
- reading configuration from the fdt
- allowing the fdt to specify a boot command


Abhilash Kesavan (2):
  fdt: Add function to get config int from device tree
  fdt: Add function for decoding multiple gpios globally available

Che-Liang Chiou (2):
  fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property
  fdt: Load boot command from device tree

Doug Anderson (1):
  fdt: Allow device tree to specify secure booting

Gabe Black (3):
  fdt: Add function to read boolean property
  fdt: Tell the FDT library where the device tree is
  fdt: Add option to default to most compatible conf in a fit image

Sean Paul (1):
  fdt: Add polarity-aware gpio functions to fdtdec

Simon Glass (5):
  fdt: Add function to get a config string from device tree
  fdt: Add fdtdec_decode_region() to decode memory region
  fdt: Export fdtdec_find_alias_node() function
  fdt: Export fdtdec_lookup() and fix the name
  fdt: Set kernaddr if fdt indicates a kernel is present

 README |   11 +
 common/cmd_bootm.c |   11 +
 common/image.c |  127 
 common/main.c  |  102 +-
 include/fdtdec.h   |  121 +
 include/image.h|1 +
 lib/fdtdec.c   |  107 +---
 7 files changed, 472 insertions(+), 8 deletions(-)

-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 08/14] fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property

[Simon Glass]

From: Che-Liang Chiou clch...@chromium.org

It decodes a 64-bit value from a property that is at least 8 bytes long.

Signed-off-by: Che-Liang Chiou clch...@chromium.org

Signed-off-by: Simon Glass s...@chromium.org
---
 include/fdtdec.h |   15 +++
 lib/fdtdec.c |   13 +
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 82fdb99..12f73a7 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -191,6 +191,21 @@ s32 fdtdec_get_int(const void *blob, int node, const char 
*prop_name,
s32 default_val);
 
 /**
+ * Look up a 64-bit integer property in a node and return it. The property
+ * must have at least 8 bytes of data (2 cells). The first two cells are
+ * concatenated to form a 8 bytes value, where the first cell is top half and
+ * the second cell is bottom half.
+ *
+ * @param blob FDT blob
+ * @param node node to examine
+ * @param prop_namename of property to find
+ * @param default_val  default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+uint64_t fdtdec_get_uint64(const void *blob, int node, const char *prop_name,
+   uint64_t default_val);
+
+/**
  * Checks whether a node is enabled.
  * This looks for a 'status' property. If this exists, then returns 1 if
  * the status is 'ok' and 0 otherwise. If there is no status property,
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index fbb2827..6c417d2 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -111,6 +111,19 @@ s32 fdtdec_get_int(const void *blob, int node, const char 
*prop_name,
return default_val;
 }
 
+uint64_t fdtdec_get_uint64(const void *blob, int node, const char *prop_name,
+   uint64_t default_val)
+{
+   const uint64_t *cell64;
+   int length;
+
+   cell64 = fdt_getprop(blob, node, prop_name, length);
+   if (!cell64 || length  sizeof(*cell64))
+   return default_val;
+
+   return fdt64_to_cpu(*cell64);
+}
+
 int fdtdec_get_is_enabled(const void *blob, int node)
 {
const char *cell;
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 02/14] fdt: Add function to get a config string from device tree

[Simon Glass]

Add a function to look up a configuration string such as board name
and returns its value. We look in the /config node for this.

Signed-off-by: Simon Glass s...@chromium.org
---
 include/fdtdec.h |   10 ++
 lib/fdtdec.c |   28 ++--
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index d880fe8..e828662 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -367,6 +367,16 @@ int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
 int fdtdec_get_config_int(const void *blob, const char *prop_name,
int default_val);
 
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a string.
+ *
+ * @param blob  FDT blob
+ * @param prop_name property name to look up
+ * @returns property string, NULL on error.
+ */
+char *fdtdec_get_config_string(const void *blob, const char *prop_name);
+
 /*
  * Look up a property in a node and return its contents in a byte
  * array of given length. The property must have at least enough data for
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 1f50022..2d60c8a 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -513,16 +513,6 @@ const u8 *fdtdec_locate_byte_array(const void *blob, int 
node,
return cell;
 }
 
-/**
- * Look in the FDT for a config item with the given name and return its value
- * as a 32-bit integer. The property must have at least 4 bytes of data. The
- * value of the first cell is returned.
- *
- * @param blob FDT blob to use
- * @param prop_nameNode property name
- * @param default_val  default value to return if the property is not found
- * @return integer value, if found, or default_val if not
- */
 int fdtdec_get_config_int(const void *blob, const char *prop_name,
int default_val)
 {
@@ -534,3 +524,21 @@ int fdtdec_get_config_int(const void *blob, const char 
*prop_name,
return default_val;
return fdtdec_get_int(blob, config_node, prop_name, default_val);
 }
+
+char *fdtdec_get_config_string(const void *blob, const char *prop_name)
+{
+   const char *nodep;
+   int nodeoffset;
+   int len;
+
+   debug(%s: %s\n, __func__, prop_name);
+   nodeoffset = fdt_path_offset(blob, /config);
+   if (nodeoffset  0)
+   return NULL;
+
+   nodep = fdt_getprop(blob, nodeoffset, prop_name, len);
+   if (!nodep)
+   return NULL;
+
+   return (char *)nodep;
+}
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 07/14] fdt: Add function to read boolean property

[Simon Glass]

From: Gabe Black gabebl...@chromium.org

Signed-off-by: Vincent Palatin vpala...@chromium.org

Commit-Ready: Vincent Palatin vpala...@chromium.org
Commit-Ready: Gabe Black gabebl...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
 include/fdtdec.h |   10 ++
 lib/fdtdec.c |   14 ++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 3f1840c..82fdb99 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -408,6 +408,16 @@ int fdtdec_get_config_int(const void *blob, const char 
*prop_name,
int default_val);
 
 /**
+ * Look in the FDT for a config item with the given name
+ * and return whether it exists.
+ *
+ * @param blob FDT blob
+ * @param prop_nameproperty name to look up
+ * @return 1, if it exists, or 0 if not
+ */
+int fdtdec_get_config_bool(const void *blob, const char *prop_name);
+
+/**
  * Look in the FDT for a config item with the given name and return its value
  * as a string.
  *
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index efe9afe..fbb2827 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -524,6 +524,20 @@ int fdtdec_get_config_int(const void *blob, const char 
*prop_name,
return fdtdec_get_int(blob, config_node, prop_name, default_val);
 }
 
+int fdtdec_get_config_bool(const void *blob, const char *prop_name)
+{
+   int config_node;
+   const void *prop;
+
+   debug(%s: %s\n, __func__, prop_name);
+   config_node = fdt_path_offset(blob, /config);
+   if (config_node  0)
+   return 0;
+   prop = fdt_get_property(blob, config_node, prop_name, NULL);
+
+   return prop != NULL;
+}
+
 char *fdtdec_get_config_string(const void *blob, const char *prop_name)
 {
const char *nodep;
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 10/14] fdt: Load boot command from device tree

[Simon Glass]

From: Che-Liang Chiou clch...@chromium.org

Load boot command from /config/bootcmd of device tree if present.

Signed-off-by: Tom Wai-Hong Tam waih...@chromium.org
Signed-off-by: Che-Liang Chiou clch...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
 common/main.c |   16 +++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/common/main.c b/common/main.c
index 9507cec..23a68ee 100644
--- a/common/main.c
+++ b/common/main.c
@@ -30,6 +30,7 @@
 #include common.h
 #include watchdog.h
 #include command.h
+#include fdtdec.h
 #include malloc.h
 #include version.h
 #ifdef CONFIG_MODEM_SUPPORT
@@ -40,6 +41,10 @@
 #include hush.h
 #endif
 
+#ifdef CONFIG_OF_CONTROL
+#include fdtdec.h
+#endif
+
 #include post.h
 #include linux/ctype.h
 #include menu.h
@@ -284,7 +289,10 @@ void main_loop (void)
int rc = 1;
int flag;
 #endif
-
+#if defined(CONFIG_BOOTDELAY)  (CONFIG_BOOTDELAY = 0)  \
+   defined(CONFIG_OF_CONTROL)
+   char *env;
+#endif
 #if defined(CONFIG_BOOTDELAY)  (CONFIG_BOOTDELAY = 0)
char *s;
int bootdelay;
@@ -380,6 +388,12 @@ void main_loop (void)
else
 #endif /* CONFIG_BOOTCOUNT_LIMIT */
s = getenv (bootcmd);
+#ifdef CONFIG_OF_CONTROL
+   /* Allow the fdt to override the boot command */
+   env = fdtdec_get_config_string(gd-fdt_blob, bootcmd);
+   if (env)
+   s = env;
+#endif /* CONFIG_OF_CONTROL */
 
debug (### main_loop: bootcmd=\%s\\n, s ? s : UNDEFINED);
 
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 11/14] fdt: Tell the FDT library where the device tree is

[Simon Glass]

From: Gabe Black gabebl...@chromium.org

This change adds a call to set_working_fdt_addr near the end of u-boot
initialization which tells the fdt command/library where the device tree is.
This makes it possible to use the fdt command to look at the active device tree
since otherwise there would be no way to know what address it was at to set
things up manually.

Signed-off-by: Gabe Black gabebl...@google.com
Signed-off-by: Simon Glass s...@chromium.org
---
 common/main.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/common/main.c b/common/main.c
index 23a68ee..cf1b5f9 100644
--- a/common/main.c
+++ b/common/main.c
@@ -45,6 +45,10 @@
 #include fdtdec.h
 #endif
 
+#ifdef CONFIG_OF_LIBFDT
+#include fdt_support.h
+#endif /* CONFIG_OF_LIBFDT */
+
 #include post.h
 #include linux/ctype.h
 #include menu.h
@@ -418,6 +422,10 @@ void main_loop (void)
 #endif /* CONFIG_MENUKEY */
 #endif /* CONFIG_BOOTDELAY */
 
+#if defined CONFIG_OF_CONTROL
+   set_working_fdt_addr((void *)gd-fdt_blob);
+#endif /* CONFIG_OF_CONTROL */
+
/*
 * Main Loop for Monitor Command Processing
 */
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 06/14] fdt: Export fdtdec_lookup() and fix the name

[Simon Glass]

The name of this function is not consistent, so fix it, and export
the function for external use.

Signed-off-by: Simon Glass s...@chromium.org
---
 include/fdtdec.h |   13 +
 lib/fdtdec.c |2 +-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index e566e47..3f1840c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -110,6 +110,19 @@ int fdtdec_next_alias(const void *blob, const char *name,
enum fdt_compat_id id, int *upto);
 
 /**
+ * Find the compatible ID for a given node.
+ *
+ * Generally each node has at least one compatible string attached to it.
+ * This function looks through our list of known compatible strings and
+ * returns the corresponding ID which matches the compatible string.
+ *
+ * @param blob FDT blob to use
+ * @param node Node containing compatible string to find
+ * @return compatible ID, or COMPAT_UNKNOWN if we cannot find a match
+ */
+enum fdt_compat_id fdtdec_lookup(const void *blob, int node);
+
+/**
  * Look in the FDT for an alias with the given name and return its node.
  *
  * @param blob FDT blob
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 16435b7..efe9afe 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -128,7 +128,7 @@ int fdtdec_get_is_enabled(const void *blob, int node)
return 1;
 }
 
-enum fdt_compat_id fd_dec_lookup(const void *blob, int node)
+enum fdt_compat_id fdtdec_lookup(const void *blob, int node)
 {
enum fdt_compat_id id;
 
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 01/14] fdt: Add function to get config int from device tree

[Simon Glass]

From: Abhilash Kesavan a.kesa...@samsung.com

Add a function to look up a configuration item such as machine id
and return its value.

Note: The code has been taken as is from the Chromium u-boot development
tree and needs Simon Glass' sign-off.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Simon Glass s...@chromium.org
---
 include/fdtdec.h |   13 +
 lib/fdtdec.c |   22 ++
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 0b14075..d880fe8 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -354,6 +354,19 @@ int fdtdec_decode_gpio(const void *blob, int node, const 
char *prop_name,
  */
 int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
 
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a 32-bit integer. The property must have at least 4 bytes of data. The
+ * value of the first cell is returned.
+ *
+ * @param blob FDT blob to use
+ * @param prop_nameNode property name
+ * @param default_val  default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+int fdtdec_get_config_int(const void *blob, const char *prop_name,
+   int default_val);
+
 /*
  * Look up a property in a node and return its contents in a byte
  * array of given length. The property must have at least enough data for
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4c23f45..1f50022 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -512,3 +512,25 @@ const u8 *fdtdec_locate_byte_array(const void *blob, int 
node,
return NULL;
return cell;
 }
+
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a 32-bit integer. The property must have at least 4 bytes of data. The
+ * value of the first cell is returned.
+ *
+ * @param blob FDT blob to use
+ * @param prop_nameNode property name
+ * @param default_val  default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+int fdtdec_get_config_int(const void *blob, const char *prop_name,
+   int default_val)
+{
+   int config_node;
+
+   debug(%s: %s\n, __func__, prop_name);
+   config_node = fdt_path_offset(blob, /config);
+   if (config_node  0)
+   return default_val;
+   return fdtdec_get_int(blob, config_node, prop_name, default_val);
+}
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 12/14] fdt: Allow device tree to specify secure booting

[Simon Glass]

From: Doug Anderson diand...@chromium.org

When secure booting is chosen:
* The u-boot shell is never invoked during boot--we just do a simple
  table lookup to find the command.  This means we could even remove
  the shell parsing from u-boot and still be able to boot.
* The boot command can't be interruped.
* Failure doesn't cause us to fall back to the shell.

Signed-off-by: Gabe Black gabebl...@google.com
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
 common/main.c |   62 +
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/common/main.c b/common/main.c
index cf1b5f9..03c63b4 100644
--- a/common/main.c
+++ b/common/main.c
@@ -283,6 +283,59 @@ int abortboot(int bootdelay)
 # endif/* CONFIG_AUTOBOOT_KEYED */
 #endif /* CONFIG_BOOTDELAY = 0  */
 
+/*
+ * Runs the given boot command securely.  Specifically:
+ * - Doesn't run the command with the shell (run_command or 
parse_string_outer),
+ *   since that's a lot of code surface that an attacker might exploit.
+ *   Because of this, we don't do any argument parsing--the secure boot command
+ *   has to be a full-fledged u-boot command.
+ * - Doesn't check for keypresses before booting, since that could be a
+ *   security hole; also disables Ctrl-C.
+ * - Doesn't allow the command to return.
+ *
+ * Upon any failures, this function will drop into an infinite loop after
+ * printing the error message to console.
+ */
+
+#if defined(CONFIG_BOOTDELAY)  (CONFIG_BOOTDELAY = 0)  \
+   defined(CONFIG_OF_CONTROL)
+static void secure_boot_cmd(char *cmd)
+{
+   cmd_tbl_t *cmdtp;
+   int rc;
+
+   if (!cmd) {
+   printf(## Error: Secure boot command not specified\n);
+   goto err;
+   }
+
+   /* Disable Ctrl-C just in case some command is used that checks it. */
+   disable_ctrlc(1);
+
+   /* Find the command directly. */
+   cmdtp = find_cmd(cmd);
+   if (!cmdtp) {
+   printf(## Error: \%s\ not defined\n, cmd);
+   goto err;
+   }
+
+   /* Run the command, forcing no flags and faking argc and argv. */
+   rc = (cmdtp-cmd)(cmdtp, 0, 1, cmd);
+
+   /* Shouldn't ever return from boot command. */
+   printf(## Error: \%s\ returned (code %d)\n, cmd, rc);
+
+err:
+   /*
+* Not a whole lot to do here.  Rebooting won't help much, since we'll
+* just end up right back here.  Just loop.
+*/
+   hang();
+}
+
+#endif /* CONFIG_OF_CONTROL */
+
+
 //
 
 void main_loop (void)
@@ -397,6 +450,15 @@ void main_loop (void)
env = fdtdec_get_config_string(gd-fdt_blob, bootcmd);
if (env)
s = env;
+
+   /*
+* If the bootsecure option was chosen, use secure_boot_cmd().
+* Always use 'env' in this case, since bootsecure requres that the
+* bootcmd was specified in the FDT too.
+*/
+   if (fdtdec_get_config_int(gd-fdt_blob, bootsecure, 0))
+   secure_boot_cmd(env);
+
 #endif /* CONFIG_OF_CONTROL */
 
debug (### main_loop: bootcmd=\%s\\n, s ? s : UNDEFINED);
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 14/14] fdt: Set kernaddr if fdt indicates a kernel is present

[Simon Glass]

If kernel-offset is specified in the fdt, set an environment variable
so that scripts can access the attached kernel.

This can be used by a packaging program to tell U-Boot about a kernel
that has been downloaded alongside U-Boot. The value in the fdt is
the offset of the kernel from the start of the U-Boot image, so we can
find it just by adding CONFIG_SYS_TEXT_BASE.

It is then fairly easy to put something like this in the environment
variables in the board header file:

if test ${kernaddr} != \\; then \
echo \Using bundled kernel\; \
bootm ${kernaddr}; \
fi; \
/* rest of boot sequence follows here */

Signed-off-by: Simon Glass s...@chromium.org
---
 common/main.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/common/main.c b/common/main.c
index 03c63b4..3137b75 100644
--- a/common/main.c
+++ b/common/main.c
@@ -333,6 +333,20 @@ err:
hang();
 }
 
+static void process_fdt_options(const void *blob)
+{
+   ulong addr;
+
+   /* Add an env variable to point to a kernel payload, if available */
+   addr = fdtdec_get_config_int(gd-fdt_blob, kernel-offset, 0);
+   if (addr)
+   setenv_addr(kernaddr, (void *)(CONFIG_SYS_TEXT_BASE + addr));
+
+   /* Add an env variable to point to a root disk, if available */
+   addr = fdtdec_get_config_int(gd-fdt_blob, rootdisk-offset, 0);
+   if (addr)
+   setenv_addr(rootaddr, (void *)(CONFIG_SYS_TEXT_BASE + addr));
+}
 #endif /* CONFIG_OF_CONTROL */
 
 
@@ -451,6 +465,8 @@ void main_loop (void)
if (env)
s = env;
 
+   process_fdt_options(gd-fdt_blob);
+
/*
 * If the bootsecure option was chosen, use secure_boot_cmd().
 * Always use 'env' in this case, since bootsecure requres that the
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 13/14] fdt: Add option to default to most compatible conf in a fit image

[Simon Glass]

From: Gabe Black gabebl...@chromium.org

When booting a fit image with multiple configurations, the user either has to
specify which configuration to use explicitly, or there has to be a default
defined which is chosen automatically. This change adds an option to change
that behavior so that a configuration can be selected explicitly, or the
configuration which has the device tree that claims to be compatible with the
earliest item in U-Boot's device tree.

In other words, if U-Boot claimed to be compatible with A, B, and then C, and
the configurations claimed to be compatible with A, D and B, D and D, E, the
first configuration, A, D, would be chosen. Both the first and second
configurations match, but the first one matches a more specific entry in
U-Boot's device tree. The order in the kernel's device tree is ignored.

Signed-off-by: Gabe Black gabebl...@google.com

Commit-Ready: Gabe Black gabebl...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
 README |   11 +
 common/cmd_bootm.c |   11 +
 common/image.c |  127 
 include/image.h|1 +
 4 files changed, 150 insertions(+), 0 deletions(-)

diff --git a/README b/README
index 69da2b8..3912150 100644
--- a/README
+++ b/README
@@ -2582,6 +2582,17 @@ FIT uImage format:
  -150  common/cmd_nand.c   Incorrect FIT image format
   151  common/cmd_nand.c   FIT image format OK
 
+- FIT image support:
+   CONFIG_FIT
+   Enable support for the FIT uImage format.
+
+   CONFIG_FIT_BEST_MATCH
+   When no configuration is explicitly selected, default to the
+   one whose fdt's compatibility field best matches that of
+   U-Boot itself. A match is considered best if it matches the
+   most specific compatibility entry of U-Boot's fdt's root node.
+   The order of entries in the configuration's fdt is ignored.
+
 - Standalone program support:
CONFIG_STANDALONE_LOAD_ADDR
 
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 83fa5d7..4e6042c 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -949,8 +949,19 @@ static void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, 
int argc,
 * node
 */
bootstage_mark(BOOTSTAGE_ID_FIT_NO_UNIT_NAME);
+#ifdef CONFIG_FIT_BEST_MATCH
+   if (fit_uname_config)
+   cfg_noffset =
+   fit_conf_get_node(fit_hdr,
+ fit_uname_config);
+   else
+   cfg_noffset =
+   fit_conf_find_compat(fit_hdr,
+gd-fdt_blob);
+#else
cfg_noffset = fit_conf_get_node(fit_hdr,
fit_uname_config);
+#endif
if (cfg_noffset  0) {
bootstage_error(BOOTSTAGE_ID_FIT_NO_UNIT_NAME);
return NULL;
diff --git a/common/image.c b/common/image.c
index 750a98b..8877395 100644
--- a/common/image.c
+++ b/common/image.c
@@ -3049,6 +3049,133 @@ int fit_check_format(const void *fit)
return 1;
 }
 
+
+/**
+ * fit_conf_find_compat
+ * @fit: pointer to the FIT format image header
+ * @fdt: pointer to the device tree to compare against
+ *
+ * fit_conf_find_compat() attempts to find the configuration whose fdt is the
+ * most compatible with the passed in device tree.
+ *
+ * Example:
+ *
+ * / o image-tree
+ *   |-o images
+ *   | |-o fdt@1
+ *   | |-o fdt@2
+ *   |
+ *   |-o configurations
+ * |-o config@1
+ * | |-fdt = fdt@1
+ * |
+ * |-o config@2
+ *   |-fdt = fdt@2
+ *
+ * / o U-Boot fdt
+ *   |-compatible = foo,bar, bim,bam
+ *
+ * / o kernel fdt1
+ *   |-compatible = foo,bar,
+ *
+ * / o kernel fdt2
+ *   |-compatible = bim,bam, baz,biz
+ *
+ * Configuration 1 would be picked because the first string in U-Boot's
+ * compatible list, foo,bar, matches a compatible string in the root of fdt1.
+ * bim,bam in fdt2 matches the second string which isn't as good as fdt1.
+ *
+ * returns:
+ * offset to the configuration to use if one was found
+ * -1 otherwise
+ */
+int fit_conf_find_compat(const void *fit, const void *fdt)
+{
+   int ndepth = 0;
+   int noffset, confs_noffset, images_noffset;
+   const void *fdt_compat;
+   int fdt_compat_len;
+   int best_match_offset = 0;
+   int best_match_pos = 0;
+
+   confs_noffset = fdt_path_offset(fit, FIT_CONFS_PATH);
+   images_noffset = fdt_path_offset(fit, FIT_IMAGES_PATH);
+   if (confs_noffset  0 || images_noffset  0) {
+   debug(Can't find configurations or images nodes.\n);
+   return -1

[PATCH 04/14] fdt: Add function for decoding multiple gpios globally available

[Simon Glass]

From: Abhilash Kesavan a.kesa...@samsung.com

Samsung's SDHCI bindings require multiple gpios to be parsed and
configured at a time. Export the already available fdtdec_decode_gpios
for this purpose.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Commit-Ready: Che-Liang Chiou clch...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
 include/fdtdec.h |   16 
 lib/fdtdec.c |5 ++---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 341e6a1..e70714b 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -345,6 +345,22 @@ int fdtdec_decode_gpio(const void *blob, int node, const 
char *prop_name,
struct fdt_gpio_state *gpio);
 
 /**
+ * Decode a list of GPIOs from an FDT. This creates a list of GPIOs with no
+ * terminating item.
+ *
+ * @param blob FDT blob to use
+ * @param node Node to look at
+ * @param prop_nameNode property name
+ * @param gpio Array of gpio elements to fill from FDT. This will be
+ * untouched if either 0 or an error is returned
+ * @param max_countMaximum number of elements allowed
+ * @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
+ * be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
+ */
+int fdtdec_decode_gpios(const void *blob, int node, const char *prop_name,
+   struct fdt_gpio_state *gpio, int max_count);
+
+/**
  * Set up a GPIO pin according to the provided gpio information. At present 
this
  * just requests the GPIO.
  *
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 5570972..32f03cc 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -426,9 +426,8 @@ int fdtdec_get_bool(const void *blob, int node, const char 
*prop_name)
  * @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
  * be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
  */
-static int fdtdec_decode_gpios(const void *blob, int node,
-   const char *prop_name, struct fdt_gpio_state *gpio,
-   int max_count)
+int fdtdec_decode_gpios(const void *blob, int node, const char *prop_name,
+   struct fdt_gpio_state *gpio, int max_count)
 {
const struct fdt_property *prop;
const u32 *cell;
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 03/14] fdt: Add fdtdec_decode_region() to decode memory region

[Simon Glass]

A memory region has a start and a size and is often specified in
a node by a 'reg' property. Add a function to decode this information
from the fdt.

Signed-off-by: Simon Glass s...@chromium.org
---
 include/fdtdec.h |   19 +++
 lib/fdtdec.c |   17 +
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index e828662..341e6a1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -40,10 +40,12 @@
 typedef u64 fdt_addr_t;
 #define FDT_ADDR_T_NONE (-1ULL)
 #define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
+#define fdt_size_to_cpu(reg) be64_to_cpu(reg)
 #else
 typedef u32 fdt_addr_t;
 #define FDT_ADDR_T_NONE (-1U)
 #define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
+#define fdt_size_to_cpu(reg) be32_to_cpu(reg)
 #endif
 
 /* Information obtained about memory from the FDT */
@@ -408,4 +410,21 @@ int fdtdec_get_byte_array(const void *blob, int node, 
const char *prop_name,
  */
 const u8 *fdtdec_locate_byte_array(const void *blob, int node,
 const char *prop_name, int count);
+
+/**
+ * Look up a property in a node which contains a memory region address and
+ * size. Then return a pointer to this address.
+ *
+ * The property must hold one address with a length. This is only tested on
+ * 32-bit machines.
+ *
+ * @param blob FDT blob
+ * @param node node to examine
+ * @param prop_namename of property to find
+ * @param ptrp returns pointer to region, or NULL if no address
+ * @param size returns size of region
+ * @return 0 if ok, -1 on error (propery not found)
+ */
+int fdtdec_decode_region(const void *blob, int node,
+   const char *prop_name, void **ptrp, size_t *size);
 #endif
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 2d60c8a..5570972 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -542,3 +542,20 @@ char *fdtdec_get_config_string(const void *blob, const 
char *prop_name)
 
return (char *)nodep;
 }
+
+int fdtdec_decode_region(const void *blob, int node,
+   const char *prop_name, void **ptrp, size_t *size)
+{
+   const fdt_addr_t *cell;
+   int len;
+
+   debug(%s: %s\n, __func__, prop_name);
+   cell = fdt_getprop(blob, node, prop_name, len);
+   if (!cell || (len != sizeof(fdt_addr_t) * 2))
+   return -1;
+
+   *ptrp = (void *)fdt_addr_to_cpu(*cell);
+   *size = fdt_size_to_cpu(cell[1]);
+   debug(%s: size=%zx\n, __func__, *size);
+   return 0;
+}
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

From: Sean Paul seanp...@chromium.org

Add get and set gpio functions to fdtdec that take into account the
polarity field in fdtdec_gpio_state.flags.

Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
 include/fdtdec.h |   16 
 lib/fdtdec.c |   20 
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 12f73a7..17daa99 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -90,6 +90,22 @@ struct fdt_gpio_state {
 #define fdt_gpio_isvalid(x) ((x)-gpio != FDT_GPIO_NONE)
 
 /**
+ * Read the GPIO taking into account the polarity of the pin.
+ *
+ * @param gpio pointer to the decoded gpio
+ * @return value of the gpio if successful,  0 if unsuccessful
+ */
+int fdtdec_get_gpio(struct fdt_gpio_state *gpio);
+
+/**
+ * Write the GPIO taking into account the polarity of the pin.
+ *
+ * @param gpio pointer to the decoded gpio
+ * @return 0 if successful
+ */
+int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val);
+
+/**
  * Find the next numbered alias for a peripheral. This is used to enumerate
  * all the peripherals of a certain type.
  *
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 6c417d2..91ba558 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -487,6 +487,26 @@ int fdtdec_decode_gpio(const void *blob, int node, const 
char *prop_name,
return err == 1 ? 0 : err;
 }
 
+int fdtdec_get_gpio(struct fdt_gpio_state *gpio)
+{
+   int val;
+
+   if (!fdt_gpio_isvalid(gpio))
+   return -1;
+
+   val = gpio_get_value(gpio-gpio);
+   return gpio-flags  FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
+}
+
+int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val)
+{
+   if (!fdt_gpio_isvalid(gpio))
+   return -1;
+
+   val = gpio-flags  FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
+   return gpio_set_value(gpio-gpio, val);
+}
+
 int fdtdec_setup_gpio(struct fdt_gpio_state *gpio)
 {
/*
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v7 03/16] tegra: fdt: Add pwm binding and node

[Simon Glass]

This binding will apparently soon be in linux-next. Bring it in now
since we need to do something, and may as well try to target what
Linux will have.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v5:
- Update Tegra PWM binding s/duty cycle/period/

Changes in v3:
- Add new commit for pwm binding and node

 arch/arm/dts/tegra20.dtsi|7 +++
 doc/device-tree-bindings/pwm/tegra20-pwm.txt |   18 ++
 2 files changed, 25 insertions(+), 0 deletions(-)
 create mode 100644 doc/device-tree-bindings/pwm/tegra20-pwm.txt

diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index d936b1e..3221bc9 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -211,4 +211,11 @@
compatible = nvidia,tegra20-nand;
reg = 0x70008000 0x100;
};
+
+   pwm: pwm@7000a000 {
+   compatible = nvidia,tegra20-pwm;
+   reg = 0x7000a000 0x100;
+   #pwm-cells = 2;
+   };
+
 };
diff --git a/doc/device-tree-bindings/pwm/tegra20-pwm.txt 
b/doc/device-tree-bindings/pwm/tegra20-pwm.txt
new file mode 100644
index 000..01438ec
--- /dev/null
+++ b/doc/device-tree-bindings/pwm/tegra20-pwm.txt
@@ -0,0 +1,18 @@
+Tegra SoC PWFM controller
+
+Required properties:
+- compatible: should be one of:
+  - nvidia,tegra20-pwm
+  - nvidia,tegra30-pwm
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The
+  first cell specifies the per-chip index of the PWM to use and the second
+  cell is the period in nanoseconds.
+
+Example:
+
+   pwm: pwm@7000a000 {
+   compatible = nvidia,tegra20-pwm;
+   reg = 0x7000a000 0x100;
+   #pwm-cells = 2;
+   };
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v7 14/16] tegra: fdt: Add LCD definitions for Seaboard

[Simon Glass]

The Seaboard has a 1366x768 16bpp LCD. The backlight is controlled
by one of the PWMs.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6:
- Add 400ms delay before enabling panel VDD

Changes in v5:
- Enable required LCD fdt nodes (which are now disabled by default)

Changes in v4:
- Adjust LCD fdt nodes for new binding
- Remove LCD frame buffer address property hack

Changes in v3:
- Use new upstream proposed LCD definitions

Changes in v2:
- Update seaboard LCD definitions for new fdt binding

 board/nvidia/dts/tegra20-seaboard.dts |   33 +
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/board/nvidia/dts/tegra20-seaboard.dts 
b/board/nvidia/dts/tegra20-seaboard.dts
index 25a63a0..dd98ca4 100644
--- a/board/nvidia/dts/tegra20-seaboard.dts
+++ b/board/nvidia/dts/tegra20-seaboard.dts
@@ -163,4 +163,37 @@
compatible = hynix,hy27uf4g2b, nand-flash;
};
};
+
+   host1x {
+   status = okay;
+   dc@5420 {
+   status = okay;
+   rgb {
+   status = okay;
+   nvidia,panel = lcd_panel;
+   };
+   };
+   };
+
+   lcd_panel: panel {
+   /* Seaboard has 1366x768 */
+   clock = 7060;
+   xres = 1366;
+   yres = 768;
+   left-margin = 58;
+   right-margin = 58;
+   hsync-len = 58;
+   lower-margin = 4;
+   upper-margin = 4;
+   vsync-len = 4;
+   hsync-active-high;
+   nvidia,bits-per-pixel = 16;
+   nvidia,pwm = pwm 2 0;
+   nvidia,backlight-enable-gpios = gpio 28 0;   /* PD4 */
+   nvidia,lvds-shutdown-gpios = gpio 10 0;  /* PB2 */
+   nvidia,backlight-vdd-gpios = gpio 176 0; /* PW0 */
+   nvidia,panel-vdd-gpios = gpio 22 0;  /* PC6 */
+   nvidia,panel-timings = 400 4 203 17 15;
+   };
+
 };
-- 
1.7.7.3

___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[PATCH v7 04/16] tegra: fdt: Add LCD definitions for Tegra

[Simon Glass]

Add LCD definitions and also a proposed binding for LCD displays.

The PWM is as per what will likely be committed to linux-next soon.

The displaymode binding comes from a proposal here:

http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html

The panel binding is new, and fills a need to specify the panel
timings and other tegra-specific information. Should a binding appear
that allows the pwm to handle this automatically, we can revisit
this.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6:
- Add an additional delay before enabling the panel

Changes in v5:
- Make all Tegra LCD fdt nodes disabled by default

Changes in v4:
- Moved panel information into panel node (was in rgb node)
- Remove LCD frame buffer address property hack

Changes in v3:
- Use displaymode binding for fdt
- Bring in proposed tegra display controller binding
- Add new panel binding to fit with tegra display controller binding

Changes in v2:
- Add nvidia prefix to device tree properties

 arch/arm/dts/tegra20.dtsi  |   98 
 doc/device-tree-bindings/video/displaymode.txt |   42 ++
 doc/device-tree-bindings/video/tegra20-dc.txt  |   85 
 3 files changed, 225 insertions(+), 0 deletions(-)
 create mode 100644 doc/device-tree-bindings/video/displaymode.txt
 create mode 100644 doc/device-tree-bindings/video/tegra20-dc.txt

diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 3221bc9..636ec2c 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -218,4 +218,102 @@
#pwm-cells = 2;
};
 
+   host1x {
+   compatible = nvidia,tegra20-host1x, simple-bus;
+   reg = 0x5000 0x00024000;
+   interrupts = 0 65 0x04   /* mpcore syncpt */
+ 0 67 0x04; /* mpcore general */
+   status = disabled;
+
+   #address-cells = 1;
+   #size-cells = 1;
+
+   ranges = 0x5400 0x5400 0x0400;
+
+   /* video-encoding/decoding */
+   mpe {
+   reg = 0x5404 0x0004;
+   interrupts = 0 68 0x04;
+   status = disabled;
+   };
+
+   /* video input */
+   vi {
+   reg = 0x5408 0x0004;
+   interrupts = 0 69 0x04;
+   status = disabled;
+   };
+
+   /* EPP */
+   epp {
+   reg = 0x540c 0x0004;
+   interrupts = 0 70 0x04;
+   status = disabled;
+   };
+
+   /* ISP */
+   isp {
+   reg = 0x5410 0x0004;
+   interrupts = 0 71 0x04;
+   status = disabled;
+   };
+
+   /* 2D engine */
+   gr2d {
+   reg = 0x5414 0x0004;
+   interrupts = 0 72 0x04;
+   status = disabled;
+   };
+
+   /* 3D engine */
+   gr3d {
+   reg = 0x5418 0x0004;
+   status = disabled;
+   };
+
+   /* display controllers */
+   dc@5420 {
+   compatible = nvidia,tegra20-dc;
+   reg = 0x5420 0x0004;
+   interrupts = 0 73 0x04;
+   status = disabled;
+
+   rgb {
+   status = disabled;
+   };
+   };
+
+   dc@5424 {
+   compatible = nvidia,tegra20-dc;
+   reg = 0x5424 0x0004;
+   interrupts = 0 74 0x04;
+   status = disabled;
+
+   rgb {
+   status = disabled;
+   };
+   };
+
+   /* outputs */
+   hdmi {
+   compatible = nvidia,tegra20-hdmi;
+   reg = 0x5428 0x0004;
+   interrupts = 0 75 0x04;
+   status = disabled;
+   };
+
+   tvo {
+   compatible = nvidia,tegra20-tvo;
+   reg = 0x542c 0x0004;
+   interrupts = 0 76 0x04;
+   status = disabled;
+   };
+
+   dsi {
+   compatible = nvidia,tegra20-dsi;
+   reg = 0x5430 0x0004;
+   status = disabled;
+   };
+   };
+
 };
diff --git a/doc/device-tree-bindings/video/displaymode.txt 
b/doc/device-tree-bindings/video/displaymode.txt
new file mode 100644
index 000..45ca42d
--- /dev/null

Re: [PATCH v4 04/16] tegra: fdt: Add LCD definitions for Tegra

[Simon Glass]

Hi Stephen,

On Wed, Oct 3, 2012 at 3:58 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 09/27/2012 06:44 PM, Simon Glass wrote:
 Add LCD definitions and also a proposed binding for LCD displays.

 The PWM is as per what will likely be committed to linux-next soon.

 The displaymode binding comes from a proposal here:

 http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html

 The panel binding is new, and fills a need to specify the panel
 timings and other tegra-specific information. Should a binding appear
 that allows the pwm to handle this automatically, we can revisit
 this.

 diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi

 + host1x {
 + compatible = nvidia,tegra20-host1x, simple-bus;
 + reg = 0x5000 0x00024000;
 + interrupts = 0 65 0x04   /* mpcore syncpt */
 +   0 67 0x04; /* mpcore general */
 +
 + #address-cells = 1;
 + #size-cells = 1;
 +
 + ranges = 0x5400 0x5400 0x0400;
 +
 + /* video-encoding/decoding */
 + mpe {
 + reg = 0x5404 0x0004;
 + interrupts = 0 68 0x04;
 + };

 Shouldn't all of these nodes have status=disabled, since in general
 boards will want to opt-in to these modules. In fact, many of these
 nodes won't end up (ever?) being used in U-Boot; perhaps we should only
 add the nodes we care about.

 + /* display controllers */
 + dc@5420 {
 + compatible = nvidia,tegra20-dc;
 + reg = 0x5420 0x0004;
 + interrupts = 0 73 0x04;
 +
 + rgb {
 + status = disabled;
 + };
 + };

 I think we definitely want status=disabled in the dc nodes themselves,
 since we definitely want boards in U-Boot to control whether to enable
 the dc.


OK I will update these, thanks.

Regards,
Simon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss