RE: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Luis R. Rodriguez
> Sent: Friday, March 04, 2016 4:45 PM
> Subject: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on
> PAT / non-PAT systems"
...
> +MMIO and another PCI BAR for write-combing, if needed.

typo: combining



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

Re: [PATCH v17 2/6] ARM: socfpga: add bindings document for fpga bridge drivers

[Rob Herring]

On Thu, Feb 25, 2016 at 05:25:07PM -0600, Alan Tull wrote:
> Add bindings documentation for Altera SOCFPGA bridges:
>  * fpga2sdram
>  * fpga2hps
>  * hps2fpga
>  * lwhps2fpga
> 
> Signed-off-by: Alan Tull 
> Signed-off-by: Matthew Gerlach 
> Signed-off-by: Dinh Nguyen 
> ---
> v2:  separate into 2 documents for the 2 drivers
> v12: bump version to line up with simple-fpga-bus version
>  remove Linux specific notes such as references to sysfs
>  move non-DT specific documentation elsewhere
>  remove bindings that would have been used to pass configuration
>  clean up formatting
> v13: Remove 'label' property
>  Change property from init-val to bridge-enable
>  Fix email address
> v14: Add resets
>  Change order of bridges to put lw bridge (controlling bridge) first
> v15: No change in this patch for v15 of this patch set
> v16: Added regs property, cleaned up unit addresses
> v17: No change to this patch in v17 of patch set
> ---
>  .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +++
>  .../bindings/fpga/altera-hps2fpga-bridge.txt   |   47 
> 
>  2 files changed, 62 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt

Just a few minor things.

> diff --git 
> a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
> b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> new file mode 100644
> index 000..4479a79
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> @@ -0,0 +1,15 @@
> +Altera FPGA To SDRAM Bridge Driver
> +
> +Required properties:
> +- compatible : Should contain "altr,socfpga-fpga2sdram-bridge"
> +
> +Optional properties:
> +- bridge-enable  : 0 if driver should disable bridge at startup
> +   1 if driver should enable bridge at startup
> +   Default is to leave bridge in current state.
> +
> +Example:
> + fpga2sdram_br {

fpga-bridge@??

> + compatible = "altr,socfpga-fpga2sdram-bridge";
> + bridge-enable = <0>;
> + };
> diff --git 
> a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt 
> b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> new file mode 100644
> index 000..e6b7474
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> @@ -0,0 +1,47 @@
> +Altera FPGA/HPS Bridge Driver
> +
> +Required properties:
> +- regs   : base address and size for AXI bridge module
> +- compatible : Should contain one of:
> +   "altr,socfpga-lwhps2fpga-bridge",
> +   "altr,socfpga-hps2fpga-bridge", or
> +   "altr,socfpga-fpga2hps-bridge"
> +- reset-names: Should contain one of:
> +   "lwhps2fpga",
> +   "hps2fpga", or
> +   "fpga2hps"

Names should be the input signal names. Do you need names with only one?

> +- resets : Phandle and reset specifier for the reset listed in
> +   reset-names
> +- clocks : Clocks used by this module.
> +
> +Optional properties:
> +- bridge-enable  : 0 if driver should disable bridge at startup.
> +   1 if driver should enable bridge at startup.
> +   Default is to leave bridge in its current state.
> +
> +Example:
> + hps_fpgabridge0: fpgabridge@ff40 {

No underscores.

fpga-bridge@...

> + compatible = "altr,socfpga-lwhps2fpga-bridge";
> + reg = <0xff40 0x10>;
> + resets = < LWHPS2FPGA_RESET>;
> + reset-names = "lwhps2fpga";
> + clocks = <_main_clk>;
> + bridge-enable = <0>;
> + };
> +
> + hps_fpgabridge1: fpgabridge@ff50 {
> + compatible = "altr,socfpga-hps2fpga-bridge";
> + reg = <0xff50 0x1>;
> + resets = < HPS2FPGA_RESET>;
> + reset-names = "hps2fpga";
> + clocks = <_main_clk>;
> + bridge-enable = <1>;
> + };
> +
> + hps_fpgabridge2: fpgabridge@ff60 {
> + compatible = "altr,socfpga-fpga2hps-bridge";
> + reg = <0xff60 0x10>;
> + resets = < FPGA2HPS_RESET>;
> + reset-names = "fpga2hps";
> + clocks = <_main_clk>;
> + };
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

[Rob Herring]

On Thu, Mar 03, 2016 at 03:38:35PM +, Ramesh Shanmugasundaram wrote:
> This patch adds support for the CAN FD controller found in Renesas R-Car
> SoCs. The controller operates in CAN FD mode by default.
> 
> CAN FD mode supports both Classical CAN & CAN FD frame formats. The
> controller supports ISO 11898-1:2015 CAN FD format only.
> 
> This controller supports two channels and the driver can enable either
> or both of the channels.
> 
> Driver uses Rx FIFOs (one per channel) for reception & Common FIFOs (one
> per channel) for transmission. Rx filter rules are configured to the
> minimum (one per channel) and it accepts Standard, Extended, Data &
> Remote Frame combinations.
> 
> Note: There are few documentation errors in R-Car Gen3 Hardware User
> Manual v0.5E with respect to CAN FD controller. They are listed below:
> 
> 1. CAN FD interrupt numbers 29 & 30 are listed as per channel
> interrupts. However, they are common to both channels (i.e.) they are
> global and channel interrupts respectively.
> 
> 2. CANFD clock is derived from PLL1. This is not documented.
> 
> 3. CANFD clock is further divided by (1/2) within the CAN FD controller.
> This is not documented.
> 
> 4. The minimum value of NTSEG1 in RSCFDnCFDCmNCFG register is 2 Tq. It
> is mentioned 4 Tq in the manual.
> 
> 5. The maximum number of message RAM area the controller can use is 3584
> bytes. It is specified 10752 bytes in the manual.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
> Changes since v1:
>   * Removed testmodes & debugfs code (suggested by Oliver H)
>   * Fixed tx path race issue by introducing lock (suggested by Marc K)
>   * Removed __maybe_unused attribute of rcar_canfd_of_table
> 
> Thanks,
> Ramesh
> ---
>  .../devicetree/bindings/net/can/rcar_canfd.txt |   86 ++
>  drivers/net/can/Kconfig|   10 +
>  drivers/net/can/Makefile   |1 +
>  drivers/net/can/rcar_canfd.c   | 1624 
> 
>  4 files changed, 1721 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/can/rcar_canfd.txt
>  create mode 100644 drivers/net/can/rcar_canfd.c
> 
> diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt 
> b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
> new file mode 100644
> index 000..4299bd8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
> @@ -0,0 +1,86 @@
> +Renesas R-Car CAN FD controller Device Tree Bindings
> +
> +
> +Required properties:
> +- compatible: Must contain one or more of the following:
> +  - "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
> +  - "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
> +
> +  When compatible with the generic version, nodes must list the
> +  SoC-specific version corresponding to the platform first, followed by the
> +  family-specific and/or generic versions.
> +
> +- reg: physical base address and size of the R-Car CAN FD register map.
> +- interrupts: interrupt specifier for the Global & Channel interrupts
> +- clocks: phandles and clock specifiers for 3 clock inputs.
> +- clock-names: 3 clock input name strings: "fck", "canfd", "can_clk".
> +- pinctrl-0: pin control group to be used for this controller.
> +- pinctrl-names: must be "default".
> +
> +Required properties for "renesas,r8a7795-canfd" compatible:
> +In R8A7795 SoC, canfd clock is a div6 clock and can be used by both CAN
> +and CAN FD controller at the same time. It needs to be scaled to maximum
> +frequency if any of these controllers use it. This is done using the
> +below properties.
> +
> +- assigned-clocks: phandle of canfd clock.
> +- assigned-clock-rates: maximum frequency of this clock.
> +
> +Each channel is represented as a child node. They can be enabled/disabled
> +using "status" property.

How many channels? Required or optional?

> +
> +Example
> +---
> +
> +SoC common .dtsi file:
> +
> + canfd: canfd@e66c {

can@e66c

> + compatible = "renesas,r8a7795-canfd",
> +  "renesas,rcar-gen3-canfd";
> + reg = <0 0xe66c 0 0x8000>;
> + interrupts = ,
> +;
> + clocks = < CPG_MOD 914>,
> +< CPG_CORE R8A7795_CLK_CANFD>,
> +<_clk>;
> + clock-names = "fck", "canfd", "can_clk";
> + assigned-clocks = < CPG_CORE R8A7795_CLK_CANFD>;
> + assigned-clock-rates = <4000>;
> + power-domains = <>;
> + status = "disabled";
> +
> + channel0 {
> + status = "disabled";
> + };
> +
> + channel1 {
> +  

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[kbuild test robot]

Hi Arnd,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.5-rc6 next-20160304]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Arnd-Bergmann/isdn-icn-remove-a-warning/20160303-031435
config: m68k-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All warnings (new ones prefixed by >>):

   In file included from arch/m68k/include/asm/io_mm.h:26:0,
from arch/m68k/include/asm/io.h:4,
from include/linux/io.h:25,
from drivers/staging/i4l/icn/icn.h:41,
from drivers/staging/i4l/icn/icn.c:12:
   drivers/staging/i4l/icn/icn.c: In function 'icn_shiftout':
   arch/m68k/include/asm/raw_io.h:43:32: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
#define out_8(addr,b) (void)((*(__force volatile u8 *) (addr)) = (b))
   ^
   arch/m68k/include/asm/io_mm.h:396:72: note: in expansion of macro 'out_8'
#define outb(val, port) ((port) < 1024 ? isa_rom_outb((val), (port)) : 
out_8((port), (val)))
   ^
>> drivers/staging/i4l/icn/icn.h:59:16: note: in expansion of macro 'outb'
#define OUTB_P outb
   ^
>> drivers/staging/i4l/icn/icn.c:89:3: note: in expansion of macro 'OUTB_P'
  OUTB_P((u_char) ((val >> s) & 1) ? 0xff : 0, port);
  ^

vim +/outb +59 drivers/staging/i4l/icn/icn.h

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  35  #ifdef __KERNEL__
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  36  /* Kernel 
includes */
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  37  
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  38  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  39  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  40  #include 

2584cf83 drivers/isdn/icn/icn.h Dan Williams   2015-08-10 @41  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  42  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  43  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  44  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  45  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  46  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  47  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  48  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  49  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  50  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  51  #include 

^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  52  
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  53  #endif   
   /* __KERNEL__ */
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  54  
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  55  /* some useful 
macros for debugging */
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  56  #ifdef 
ICN_DEBUG_PORT
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  57  #define 
OUTB_P(v, p) {printk(KERN_DEBUG "icn: outb_p(0x%02x,0x%03x)\n", v, p); 
outb_p(v, p);}
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  58  #else
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 @59  #define OUTB_P 
outb
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  60  #endif
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  61  
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16  62  /* Defaults for 
Port-Address and shared-memory */

:: The code at line 59 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds <torva...@ppc970.osdl.org>
:: CC: Linus Torvalds <torva...@ppc970.osdl.org>

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


.config.gz
Description: Binary data

Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"

[Luis R. Rodriguez]

On Fri, Mar 04, 2016 at 04:03:04PM -0800, Paul E. McKenney wrote:
> On Fri, Mar 04, 2016 at 02:45:01PM -0800, Luis R. Rodriguez wrote:
> > The current documentation refers to using set_memory_wc() as a
> > possible hole strategy when you have overlapping ioremap() regions,
> > that's incorrect as set_memory_*() helpers can only be used on RAM,
> > not IO memory. Using set_memory_wc() will not fail, that's a problem
> > which must be corrected in the future. This fixes that, and updates
> > the documention to *strongly* discourage overlapping ioremap() memory
> > uses, but also documents a possible solution should there really be
> > no other option to remain compatible on both PAT and MTRR memory
> > constarained systems. While at it, this provides some same guidlines
> > to system designers to remain sane and compatible on both PAT and
> > non-PAT systems.
> > 
> > As per Toshi this also fixes the table for the effective memory type
> > when using MTRR WC on PAT UC- to WC.
> > 
> > Signed-off-by: Luis R. Rodriguez 
> 
> And I was really confused during my earlier reply.  For some reason
> I read the filename as memory-barriers.txt.
> 
> This one is not mine.  Too much time in standards committee meetings,
> I guess.  ;-)

Heh, OK yeah I was confused why you wanted to pick it up but played along.
Boris, can this go through you as its a follow up that previously went
through you ?

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

Re: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"

[Paul E. McKenney]

On Fri, Mar 04, 2016 at 02:45:01PM -0800, Luis R. Rodriguez wrote:
> The current documentation refers to using set_memory_wc() as a
> possible hole strategy when you have overlapping ioremap() regions,
> that's incorrect as set_memory_*() helpers can only be used on RAM,
> not IO memory. Using set_memory_wc() will not fail, that's a problem
> which must be corrected in the future. This fixes that, and updates
> the documention to *strongly* discourage overlapping ioremap() memory
> uses, but also documents a possible solution should there really be
> no other option to remain compatible on both PAT and MTRR memory
> constarained systems. While at it, this provides some same guidlines
> to system designers to remain sane and compatible on both PAT and
> non-PAT systems.
> 
> As per Toshi this also fixes the table for the effective memory type
> when using MTRR WC on PAT UC- to WC.
> 
> Signed-off-by: Luis R. Rodriguez 

And I was really confused during my earlier reply.  For some reason
I read the filename as memory-barriers.txt.

This one is not mine.  Too much time in standards committee meetings,
I guess.  ;-)

Thanx, Paul

> ---
>  Documentation/x86/pat.txt | 54 
> +++
>  1 file changed, 41 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> index 54944c71b819..6323f24f3b59 100644
> --- a/Documentation/x86/pat.txt
> +++ b/Documentation/x86/pat.txt
> @@ -112,19 +112,47 @@ before the page is freed to free pool.
>  MTRR effects on PAT / non-PAT systems
>  -
> 
> +As of v4.3 mtrr_add() has been phased out in favor of arch_phys_wc_add(),
> +these calls are a no-op on PAT enabled systems but remain MTRR effective
> +on non-PAT systems. In order for this to work properly on both PAT and
> +non-PAT systems the region over which an arch_phys_wc_add() is made should be
> +ioremapped with WC attributes or PAT entries, using ioremap_wc().
> +
> +To enable simplifying device drivers, and to help support PAT and remain
> +compatible with non-PAT systems, PCI devices are encouraged to dedicate a 
> full
> +PCI bar for different intended regions of IO, for instance one PCI BAR for
> +MMIO and another PCI BAR for write-combing, if needed.
> +
> +Firmware should always expose to the operating system where write-combining 
> is
> +desirable, otherwise PAT cannot be supported, PAT systems need to know the
> +physical address of the area where write-combining is desirable.
> +
> +Devices which use a single PCI BAR to combine different areas of IO memory
> +must use separate ioremap() calls for each type of intended IO memory.
> +Physically overlapping ioremap calls are strongly discouraged and may soon be
> +disallowed. Devices that have one PCI BAR with an area of IO where
> +write-combining is desirable followed contiguously by an area of MMIO
> +should ioremap_wc() only on the area where write-combining is desired,
> +followed by a physically non-overlapping ioremap_uc() for MMIO. Since MTRR
> +calls are limited, and since MTRR calls must be done with orders of power of 
> 2
> +on both the size and base address one may be constrained to use just one MTRR
> +call which will include the full MMIO range. In such cases, in order to 
> remain
> +compatible with PAT and functional on non-PAT systems arch_phys_wc_add() can
> +be used to enable MTRR WC on the entire PCI BAR for all the combined IO range
> +(both write-combining and MMIO range). Using ioremap_uc() ensures that a
> +MTRR WC applied to it effectively yields UC, while using ioremap_wc()
> +white-lists the MTRR WC effects over its region. For an example of this
> +strategy refer to commit 3cc2dac5be ("drivers/video/fbdev/atyfb: Replace
> +MTRR UC hole with strong UC"). Such use is nevertheless heavily discouraged
> +as the effective memory type for the write-combined area on non-PAT is
> +technically considered implementation defined. This strategy should only be
> +used used as a last resort measure.
> +
> +You cannot use set_memory_*() helpers on ioremap'd regions (IO memory), even
> +though its use currently gives no hint of an error.
> +
>  The following table provides the effects of using write-combining MTRRs when
> -using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> -mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
> -be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> -is made, should already have been ioremapped with WC attributes or PAT 
> entries,
> -this can be done by using ioremap_wc() / set_memory_wc().  Devices which
> -combine areas of IO memory desired to remain uncacheable with areas where
> -write-combining is desirable should consider use of ioremap_uc() followed by
> -set_memory_wc() to white-list effective write-combined areas.  Such use is
> -nevertheless 

[PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"

[Luis R. Rodriguez]

The current documentation refers to using set_memory_wc() as a
possible hole strategy when you have overlapping ioremap() regions,
that's incorrect as set_memory_*() helpers can only be used on RAM,
not IO memory. Using set_memory_wc() will not fail, that's a problem
which must be corrected in the future. This fixes that, and updates
the documention to *strongly* discourage overlapping ioremap() memory
uses, but also documents a possible solution should there really be
no other option to remain compatible on both PAT and MTRR memory
constarained systems. While at it, this provides some same guidlines
to system designers to remain sane and compatible on both PAT and
non-PAT systems.

As per Toshi this also fixes the table for the effective memory type
when using MTRR WC on PAT UC- to WC.

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/x86/pat.txt | 54 +++
 1 file changed, 41 insertions(+), 13 deletions(-)

diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index 54944c71b819..6323f24f3b59 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -112,19 +112,47 @@ before the page is freed to free pool.
 MTRR effects on PAT / non-PAT systems
 -
 
+As of v4.3 mtrr_add() has been phased out in favor of arch_phys_wc_add(),
+these calls are a no-op on PAT enabled systems but remain MTRR effective
+on non-PAT systems. In order for this to work properly on both PAT and
+non-PAT systems the region over which an arch_phys_wc_add() is made should be
+ioremapped with WC attributes or PAT entries, using ioremap_wc().
+
+To enable simplifying device drivers, and to help support PAT and remain
+compatible with non-PAT systems, PCI devices are encouraged to dedicate a full
+PCI bar for different intended regions of IO, for instance one PCI BAR for
+MMIO and another PCI BAR for write-combing, if needed.
+
+Firmware should always expose to the operating system where write-combining is
+desirable, otherwise PAT cannot be supported, PAT systems need to know the
+physical address of the area where write-combining is desirable.
+
+Devices which use a single PCI BAR to combine different areas of IO memory
+must use separate ioremap() calls for each type of intended IO memory.
+Physically overlapping ioremap calls are strongly discouraged and may soon be
+disallowed. Devices that have one PCI BAR with an area of IO where
+write-combining is desirable followed contiguously by an area of MMIO
+should ioremap_wc() only on the area where write-combining is desired,
+followed by a physically non-overlapping ioremap_uc() for MMIO. Since MTRR
+calls are limited, and since MTRR calls must be done with orders of power of 2
+on both the size and base address one may be constrained to use just one MTRR
+call which will include the full MMIO range. In such cases, in order to remain
+compatible with PAT and functional on non-PAT systems arch_phys_wc_add() can
+be used to enable MTRR WC on the entire PCI BAR for all the combined IO range
+(both write-combining and MMIO range). Using ioremap_uc() ensures that a
+MTRR WC applied to it effectively yields UC, while using ioremap_wc()
+white-lists the MTRR WC effects over its region. For an example of this
+strategy refer to commit 3cc2dac5be ("drivers/video/fbdev/atyfb: Replace
+MTRR UC hole with strong UC"). Such use is nevertheless heavily discouraged
+as the effective memory type for the write-combined area on non-PAT is
+technically considered implementation defined. This strategy should only be
+used used as a last resort measure.
+
+You cannot use set_memory_*() helpers on ioremap'd regions (IO memory), even
+though its use currently gives no hint of an error.
+
 The following table provides the effects of using write-combining MTRRs when
-using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
-mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
-be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
-is made, should already have been ioremapped with WC attributes or PAT entries,
-this can be done by using ioremap_wc() / set_memory_wc().  Devices which
-combine areas of IO memory desired to remain uncacheable with areas where
-write-combining is desirable should consider use of ioremap_uc() followed by
-set_memory_wc() to white-list effective write-combined areas.  Such use is
-nevertheless discouraged as the effective memory type is considered
-implementation defined, yet this strategy can be used as last resort on devices
-with size-constrained regions where otherwise MTRR write-combining would
-otherwise not be effective.
+using ioremap*() calls on x86 for both non-PAT and PAT systems.
 
 --
 MTRR Non-PAT   PATLinux ioremap valueEffective memory type
@@ -136,7 +164,7 @@ MTRR Non-PAT   PATLinux ioremap 

Re: [PATCH] x86: PAT: Documentation: update overlapping ioremap hack recommendation

[Paul E. McKenney]

On Fri, Mar 04, 2016 at 08:23:26PM +0100, Luis R. Rodriguez wrote:
> On Thu, Mar 03, 2016 at 01:42:33PM -0800, Paul E. McKenney wrote:
> > On Thu, Mar 03, 2016 at 01:21:48PM -0800, Luis R. Rodriguez wrote:
> > > The current documentation refers to using set_memor_wc() as a
> > > possible hole strategy when you have overlapping ioremap() regions,
> > > that's incorrect as set_memory_*() helpers can only be used on RAM,
> > > not IO memory. This fixes that, and updates the documention to
> > > *strongly* discourage overlapping ioremap() memory uses, but also
> > > documents a possible solution should there really be no other
> > > option.
> > > 
> > > Signed-off-by: Luis R. Rodriguez 
> > 
> > Given an Acked-by or better from the guys on the TO line, I would be
> > happy to queue it.
> 
> I'll need to respin as fortunately I ended up actually not needing
> to do an overlap on atyfb, and instead just let MTRR be effective
> over an entire range that included both write-combining and strong
> UC attributes. It was a bit fuzzy as this while ago, and since its
> also obscure, its more reason to document now.
> 
> Will spin a v2.

Sounds good!

Thanx, Paul

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

Re: [PATCH] x86: PAT: Documentation: update overlapping ioremap hack recommendation

[Luis R. Rodriguez]

On Thu, Mar 03, 2016 at 01:42:33PM -0800, Paul E. McKenney wrote:
> On Thu, Mar 03, 2016 at 01:21:48PM -0800, Luis R. Rodriguez wrote:
> > The current documentation refers to using set_memor_wc() as a
> > possible hole strategy when you have overlapping ioremap() regions,
> > that's incorrect as set_memory_*() helpers can only be used on RAM,
> > not IO memory. This fixes that, and updates the documention to
> > *strongly* discourage overlapping ioremap() memory uses, but also
> > documents a possible solution should there really be no other
> > option.
> > 
> > Signed-off-by: Luis R. Rodriguez 
> 
> Given an Acked-by or better from the guys on the TO line, I would be
> happy to queue it.

I'll need to respin as fortunately I ended up actually not needing
to do an overlap on atyfb, and instead just let MTRR be effective
over an entire range that included both write-combining and strong
UC attributes. It was a bit fuzzy as this while ago, and since its
also obscure, its more reason to document now.

Will spin a v2.

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

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[isdn]

Am 04.03.2016 um 16:24 schrieb Arnd Bergmann:
> On Thursday 03 March 2016 09:30:38 i...@linux-pingi.de wrote:
>> Hi Arnd,
>> I fully agree and ack.
>> Thanks for the work.
>>
> 
> I actually did more patches that I ended up not submitting:
> 
> * move hisax to staging
> * remove i4l support from gigaset
> * move i4l core to staging
> 
> while I initially thought that i4l as a whole is not just unmaintained
> but also more or less unused, patch 19cebbcb04c8 ("isdn: Partially
> revert debug format string usage clean up") came in that indicated that
> there are still users that even send patches for hisax, and that
> made me doubt whether we could consider it obsolete enough.
> 
> Any thoughts on this? If you like, I can send those too.

I4L is still in use on some sides and here is no 100% replacement (net
via RAW IP mode, terminal via X.75).

This week I got some question from a big retail chain  in Germany about
migration. I never know that they are  using this stuff (for initial
setup of remote shops).

So I would not drop i4l yet, maybe we should propose this for 2018.
I4L is not so usefull for NT mode, which is very popular nowadays for
gateways into the new full IP world. Some design ins with mISDN here,
mostly in the embedded area.

> 
> My main motivation was to not have to fix up the ippp implementation
> when I move the compat ioctl handler from fs/compat_ioctl.c
> into drivers/net/ppp/ppp_generic.c, but I guess I can do that
> anyway as it seems that i4l never worked properly in compat mode.
> 
>   Arnd
> 
> 
> 
> 
> 

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

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Arnd Bergmann]

On Friday 04 March 2016 17:18:23 Paul Bolle wrote:
> [Added Tilman and Christoph.]
> 
> On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote:
> > I actually did more patches that I ended up not submitting:
> > 
> > * move hisax to staging
> > * remove i4l support from gigaset
> 
> For the record: I have no reason to object a patch that does that. (I'm
> not aware anyone complained when gigaset switched its default from i4l
> to capi. By now all relevant distributions should use our capi driver.)

Ok.

> > * move i4l core to staging
> 
> On a local tree I have two (draft) patches that do some related
> preliminary work:
> - isdnhdlc: move into separate directory
> - mISDN: NETJet: stop selecting ISDN_I4L
> 
> These trivial patches untangle mISDN and i4l. Perhaps you did something
> similar in your "move i4l core to staging".

Yes, I have the same thing. I didn't mention it here as it should
be completely non-controversial.

A third patch moves the capidrv source from drivers/isdn/capi/
into the i4l directory.

> > Any thoughts on this? If you like, I can send those too.
> 
> For my part I'm surprised that anyone is still using it. But apparently
> the hardware that required commit 19cebbcb04c8 and 3460baa62068  (which
> I'm unfamiliar with) is still operational. And since there never has
> been, as far as I know, a global i4l to capi migration nor a global i4l
> (and capi) to mISDN migration it might be that some people are stuck on
> i4l drivers for their hardware. Perhaps that explains Cristoph's
> commits.

My understanding is that it's not about the hardware, and that all
devices that people actually use with hisax should also with with
mISDN.

Instead, the only argument I've heard about keeping i4l and hisax
around (indefinitely) is that existing user space tools are written
for i4l and not ported to mISDN. They work fine with CAPI drivers
using capidrv.ko, but there is no i4l emulation on top of mISDN.

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

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Paul Bolle]

[Added Tilman and Christoph.]

On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote:
> I actually did more patches that I ended up not submitting:
> 
> * move hisax to staging
> * remove i4l support from gigaset

For the record: I have no reason to object a patch that does that. (I'm
not aware anyone complained when gigaset switched its default from i4l
to capi. By now all relevant distributions should use our capi driver.)

> * move i4l core to staging

On a local tree I have two (draft) patches that do some related
preliminary work:
- isdnhdlc: move into separate directory
- mISDN: NETJet: stop selecting ISDN_I4L

These trivial patches untangle mISDN and i4l. Perhaps you did something
similar in your "move i4l core to staging".

> while I initially thought that i4l as a whole is not just unmaintained
> but also more or less unused, patch 19cebbcb04c8 ("isdn: Partially
> revert debug format string usage clean up") came in that indicated
> that
> there are still users that even send patches for hisax, and that
> made me doubt whether we could consider it obsolete enough.

See also commit 3460baa62068 ("PCI: Fix minimum allocation address
overwrite").

> Any thoughts on this? If you like, I can send those too.

For my part I'm surprised that anyone is still using it. But apparently
the hardware that required commit 19cebbcb04c8 and 3460baa62068  (which
I'm unfamiliar with) is still operational. And since there never has
been, as far as I know, a global i4l to capi migration nor a global i4l
(and capi) to mISDN migration it might be that some people are stuck on
i4l drivers for their hardware. Perhaps that explains Cristoph's
commits.

> My main motivation was to not have to fix up the ippp implementation
> when I move the compat ioctl handler from fs/compat_ioctl.c
> into drivers/net/ppp/ppp_generic.c, but I guess I can do that
> anyway as it seems that i4l never worked properly in compat mode.


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

Re: [PATCH v3 5/7] ACPI: serial: implement earlycon on ACPI DBG2 port

[Peter Hurley]

On 03/04/2016 05:03 AM, Aleksey Makarov wrote:

> Actually it was Mark Salter who asked to introduce such macros.
> 
> https://lkml.kernel.org/g/1441730339.5459.8.ca...@redhat.com

I wasn't copied on that series, sorry.


> I think reusing the OF functions is a good decision.

But you're not reusing the OF functions; you're duplicating them.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 5/7] ACPI: serial: implement earlycon on ACPI DBG2 port

[Peter Hurley]

On 03/04/2016 05:03 AM, Aleksey Makarov wrote:
> 
> 
> On 03/03/2016 08:48 PM, Peter Hurley wrote:
>> On 03/01/2016 08:57 AM, Aleksey Makarov wrote:
>>>
>>>
>>> On 03/01/2016 06:53 PM, Peter Hurley wrote:
 On 02/29/2016 04:42 AM, Aleksey Makarov wrote:
> Add ACPI_DBG2_EARLYCON_DECLARE() macros that declares
> an earlycon on the serial port specified in the DBG2 ACPI table.
>
> Pass the string "earlycon=acpi_dbg2" to the kernel to activate it.
>
> Callbacks for EARLYCON_DECLARE() and OF_EARLYCON_DECLARE()
> can also be used for this macros.
>
> Signed-off-by: Aleksey Makarov 
> ---
>  Documentation/kernel-parameters.txt |  3 ++
>  drivers/tty/serial/earlycon.c   | 60 
> +
>  include/linux/acpi_dbg2.h   | 20 +
>  3 files changed, 83 insertions(+)
>
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index e0a21e4..19b947b 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1072,6 +1072,9 @@ bytes respectively. Such letter suffixes can also 
> be entirely omitted.
>   A valid base address must be provided, and the serial
>   port must already be setup and configured.
>  
> + acpi_dbg2
> + Use serial port specified by the DBG2 ACPI table.
> +
>   earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
>   earlyprintk=vga
>   earlyprintk=efi
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index d217366..9ba3a04 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef CONFIG_FIX_EARLYCON_MEM
>  #include 
> @@ -200,6 +201,8 @@ int __init setup_earlycon(char *buf)
>   return -ENOENT;
>  }
>  
> +static bool setup_dbg2_earlycon;
> +
>  /* early_param wrapper for setup_earlycon() */
>  static int __init param_setup_earlycon(char *buf)
>  {
> @@ -212,6 +215,11 @@ static int __init param_setup_earlycon(char *buf)
>   if (!buf || !buf[0])
>   return early_init_dt_scan_chosen_serial();
>  
> + if (!strcmp(buf, "acpi_dbg2")) {
> + setup_dbg2_earlycon = true;
> + return 0;
> + }

 So this series doesn't start an ACPI earlycon at early_param time?
 That doesn't seem very useful.

 When does the ACPI earlycon actually start?
 And don't say "when the DBG2 table is probed"; that much is obvious.
>>>
>>> ACPI earlycon starts as soon as ACPI tables become accessible 
>>> (setup_arch()).
>>> I think that is still quite early.
>>
>> I see now; the probe is in patch 6/7.
>>
>> setup_arch()
>>   acpi_boot_table_init()
>> acpi_probe_device_table()
>>   ...
>> acpi_dbg2_setup()
>>   ->setup()
>> acpi_setup_earlycon()
>>
>>
> +
>   err = setup_earlycon(buf);
>   if (err == -ENOENT || err == -EALREADY)
>   return 0;
> @@ -286,3 +294,55 @@ int __init of_setup_earlycon(const struct 
> earlycon_id *match,
>  }
>  
>  #endif /* CONFIG_OF_EARLY_FLATTREE */
> +
> +#ifdef CONFIG_ACPI_DBG2_TABLE
> +
> +int __init acpi_setup_earlycon(struct acpi_dbg2_device *device, void *d)
> +{
> + int err;
> + struct uart_port *port = _console_dev.port;
> + int (*setup)(struct earlycon_device *, const char *) = d;
> + struct acpi_generic_address *reg;
> +
> + if (!setup_dbg2_earlycon)
> + return -ENODEV;
> +
> + if (device->register_count < 1)
> + return -ENODEV;
> +
> + if (device->base_address_offset >= device->length)
> + return -EINVAL;
> +
> + reg = (void *)device + device->base_address_offset;
> +
> + if (reg->space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY &&
> + reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO)
> + return -EINVAL;
> +
> + spin_lock_init(>lock);
> + port->uartclk = BASE_BAUD * 16;
> +
> + if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> + if (device->port_type == ACPI_DBG2_ARM_SBSA_32BIT)
> + port->iotype = UPIO_MEM32;
> + else
> + port->iotype = UPIO_MEM;
> + port->mapbase = reg->address;
> + port->membase = earlycon_map(reg->address, SZ_4K);
> + } else {
> + port->iotype = UPIO_PORT;
> + port->iobase = reg->address;
> + }
> +
> + early_console_dev.con->data = _console_dev;
> + err = setup(_console_dev, NULL);
> + if (err < 0)
> + return err;
> + if (!early_console_dev.con->write)

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Arnd Bergmann]

On Thursday 03 March 2016 09:30:38 i...@linux-pingi.de wrote:
> Hi Arnd,
> I fully agree and ack.
> Thanks for the work.
> 

I actually did more patches that I ended up not submitting:

* move hisax to staging
* remove i4l support from gigaset
* move i4l core to staging

while I initially thought that i4l as a whole is not just unmaintained
but also more or less unused, patch 19cebbcb04c8 ("isdn: Partially
revert debug format string usage clean up") came in that indicated that
there are still users that even send patches for hisax, and that
made me doubt whether we could consider it obsolete enough.

Any thoughts on this? If you like, I can send those too.

My main motivation was to not have to fix up the ippp implementation
when I move the compat ioctl handler from fs/compat_ioctl.c
into drivers/net/ppp/ppp_generic.c, but I guess I can do that
anyway as it seems that i4l never worked properly in compat mode.

Arnd




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

[PATCH 3/3] thermal: max77620: Add thermal driver for reporting junction temp

[Laxman Dewangan]

Maxim Semiconductor Max77620 supports alarm interrupts when
its die temperature crosses 120C and 140C. These threshold
temperatures are not configurable.

Add thermal driver to register PMIC die temperature as thermal
zone sensor and capture the die temperature warning interrupts
to notifying the client.

Signed-off-by: Laxman Dewangan 
---
 drivers/thermal/Kconfig|   9 +++
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/thermal-max77620.c | 151 +
 3 files changed, 161 insertions(+)
 create mode 100644 drivers/thermal/thermal-max77620.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 5e7c97a..faba1a3 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -194,6 +194,15 @@ config IMX_THERMAL
  cpufreq is used as the cooling device to throttle CPUs when the
  passive trip is crossed.
 
+config MAX77620_THERMAL
+   tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
+   depends on MFD_MAX77620
+   depends on OF
+   help
+ Support for die junction temperature warning alarm for Maxim
+ Semiconductor PMIC MAX77620 device. Device generates alert
+ signal/interrupt when die temperature cross its threshold.
+
 config SPEAR_THERMAL
tristate "SPEAr thermal sensor driver"
depends on PLAT_SPEAR || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 8e9cbc3..c6bc2bd 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_DOVE_THERMAL)+= dove_thermal.o
 obj-$(CONFIG_DB8500_THERMAL)   += db8500_thermal.o
 obj-$(CONFIG_ARMADA_THERMAL)   += armada_thermal.o
 obj-$(CONFIG_IMX_THERMAL)  += imx_thermal.o
+obj-$(CONFIG_MAX77620_THERMAL) += thermal-max77620.o
 obj-$(CONFIG_DB8500_CPUFREQ_COOLING)   += db8500_cpufreq_cooling.o
 obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o
 obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o
diff --git a/drivers/thermal/thermal-max77620.c 
b/drivers/thermal/thermal-max77620.c
new file mode 100644
index 000..846da62
--- /dev/null
+++ b/drivers/thermal/thermal-max77620.c
@@ -0,0 +1,151 @@
+/*
+ * Junction temperature thermal driver for Maxim Max77620.
+ *
+ * Copyright (c) 2016, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Author: Laxman Dewangan 
+ *Mallikarjun Kasoju 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX77620_NORMAL_OPERATING_TEMP 10
+#define MAX77620_TJALARM1_TEMP 12
+#define MAX77620_TJALARM1_TEMP 14
+
+struct max77620_therm_info {
+   struct device   *dev;
+   struct regmap   *rmap;
+   struct thermal_zone_device  *tz_device;
+   int irq_tjalarm1;
+   int irq_tjalarm2;
+};
+
+static int max77620_thermal_read_temp(void *data, int *temp)
+{
+   struct max77620_therm_info *mtherm = data;
+   unsigned int val;
+   int ret;
+
+   ret = regmap_read(mtherm->rmap, MAX77620_REG_STATLBT, );
+   if (ret < 0) {
+   dev_err(mtherm->dev, "Failed to read STATLBT, %d\n", ret);
+   return -EINVAL;
+   }
+
+   if (val & MAX77620_IRQ_TJALRM2_MASK)
+   *temp = MAX77620_TJALARM2_TEMP;
+   else if (val & MAX77620_IRQ_TJALRM1_MASK)
+   *temp = MAX77620_TJALARM1_TEMP;
+   else
+   *temp = MAX77620_NORMAL_OPERATING_TEMP;
+   return 0;
+}
+
+static const struct thermal_zone_of_device_ops max77620_thermal_ops = {
+   .get_temp = max77620_thermal_read_temp,
+};
+
+static irqreturn_t max77620_thermal_irq(int irq, void *data)
+{
+   struct max77620_therm_info *mtherm = data;
+
+   if (irq == mtherm->irq_tjalarm1)
+   dev_warn(mtherm->dev, "Junction Temp Alarm1(120C) occurred\n");
+   else if (irq == mtherm->irq_tjalarm2)
+   dev_warn(mtherm->dev, "Junction Temp Alarm2(140C) occurred\n");
+
+   thermal_zone_device_update(mtherm->tz_device);
+
+   return IRQ_HANDLED;
+}
+
+static int max77620_thermal_probe(struct platform_device *pdev)
+{
+   struct max77620_therm_info *mtherm;
+   int ret;
+
+   if (!pdev->dev.of_node)
+   pdev->dev.of_node = pdev->dev.parent->of_node;
+
+   mtherm = devm_kzalloc(>dev, sizeof(*mtherm), GFP_KERNEL);
+   if (!mtherm)
+   return -ENOMEM;
+
+   mtherm->irq_tjalarm1 = platform_get_irq(pdev, 0);
+   mtherm->irq_tjalarm2 = platform_get_irq(pdev, 1);
+   if ((mtherm->irq_tjalarm1 < 0) || (mtherm->irq_tjalarm2 < 

Re: [PATCH v3 5/7] ACPI: serial: implement earlycon on ACPI DBG2 port

[Aleksey Makarov]

On 03/03/2016 08:48 PM, Peter Hurley wrote:
> On 03/01/2016 08:57 AM, Aleksey Makarov wrote:
>>
>>
>> On 03/01/2016 06:53 PM, Peter Hurley wrote:
>>> On 02/29/2016 04:42 AM, Aleksey Makarov wrote:
 Add ACPI_DBG2_EARLYCON_DECLARE() macros that declares
 an earlycon on the serial port specified in the DBG2 ACPI table.

 Pass the string "earlycon=acpi_dbg2" to the kernel to activate it.

 Callbacks for EARLYCON_DECLARE() and OF_EARLYCON_DECLARE()
 can also be used for this macros.

 Signed-off-by: Aleksey Makarov 
 ---
  Documentation/kernel-parameters.txt |  3 ++
  drivers/tty/serial/earlycon.c   | 60 
 +
  include/linux/acpi_dbg2.h   | 20 +
  3 files changed, 83 insertions(+)

 diff --git a/Documentation/kernel-parameters.txt 
 b/Documentation/kernel-parameters.txt
 index e0a21e4..19b947b 100644
 --- a/Documentation/kernel-parameters.txt
 +++ b/Documentation/kernel-parameters.txt
 @@ -1072,6 +1072,9 @@ bytes respectively. Such letter suffixes can also be 
 entirely omitted.
A valid base address must be provided, and the serial
port must already be setup and configured.
  
 +  acpi_dbg2
 +  Use serial port specified by the DBG2 ACPI table.
 +
earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
earlyprintk=vga
earlyprintk=efi
 diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
 index d217366..9ba3a04 100644
 --- a/drivers/tty/serial/earlycon.c
 +++ b/drivers/tty/serial/earlycon.c
 @@ -22,6 +22,7 @@
  #include 
  #include 
  #include 
 +#include 
  
  #ifdef CONFIG_FIX_EARLYCON_MEM
  #include 
 @@ -200,6 +201,8 @@ int __init setup_earlycon(char *buf)
return -ENOENT;
  }
  
 +static bool setup_dbg2_earlycon;
 +
  /* early_param wrapper for setup_earlycon() */
  static int __init param_setup_earlycon(char *buf)
  {
 @@ -212,6 +215,11 @@ static int __init param_setup_earlycon(char *buf)
if (!buf || !buf[0])
return early_init_dt_scan_chosen_serial();
  
 +  if (!strcmp(buf, "acpi_dbg2")) {
 +  setup_dbg2_earlycon = true;
 +  return 0;
 +  }
>>>
>>> So this series doesn't start an ACPI earlycon at early_param time?
>>> That doesn't seem very useful.
>>>
>>> When does the ACPI earlycon actually start?
>>> And don't say "when the DBG2 table is probed"; that much is obvious.
>>
>> ACPI earlycon starts as soon as ACPI tables become accessible (setup_arch()).
>> I think that is still quite early.
> 
> I see now; the probe is in patch 6/7.
> 
> setup_arch()
>   acpi_boot_table_init()
> acpi_probe_device_table()
>   ...
> acpi_dbg2_setup()
>   ->setup()
> acpi_setup_earlycon()
> 
> 
 +
err = setup_earlycon(buf);
if (err == -ENOENT || err == -EALREADY)
return 0;
 @@ -286,3 +294,55 @@ int __init of_setup_earlycon(const struct earlycon_id 
 *match,
  }
  
  #endif /* CONFIG_OF_EARLY_FLATTREE */
 +
 +#ifdef CONFIG_ACPI_DBG2_TABLE
 +
 +int __init acpi_setup_earlycon(struct acpi_dbg2_device *device, void *d)
 +{
 +  int err;
 +  struct uart_port *port = _console_dev.port;
 +  int (*setup)(struct earlycon_device *, const char *) = d;
 +  struct acpi_generic_address *reg;
 +
 +  if (!setup_dbg2_earlycon)
 +  return -ENODEV;
 +
 +  if (device->register_count < 1)
 +  return -ENODEV;
 +
 +  if (device->base_address_offset >= device->length)
 +  return -EINVAL;
 +
 +  reg = (void *)device + device->base_address_offset;
 +
 +  if (reg->space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY &&
 +  reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO)
 +  return -EINVAL;
 +
 +  spin_lock_init(>lock);
 +  port->uartclk = BASE_BAUD * 16;
 +
 +  if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
 +  if (device->port_type == ACPI_DBG2_ARM_SBSA_32BIT)
 +  port->iotype = UPIO_MEM32;
 +  else
 +  port->iotype = UPIO_MEM;
 +  port->mapbase = reg->address;
 +  port->membase = earlycon_map(reg->address, SZ_4K);
 +  } else {
 +  port->iotype = UPIO_PORT;
 +  port->iobase = reg->address;
 +  }
 +
 +  early_console_dev.con->data = _console_dev;
 +  err = setup(_console_dev, NULL);
 +  if (err < 0)
 +  return err;
 +  if (!early_console_dev.con->write)
 +  return -ENODEV;
 +
 +  register_console(early_console_dev.con);
 +  return 0;
 +}
 +
 +#endif /* 

[PATCH v7 10/11] MAINTAINERS: Add maintainer for hisilicon DRM driver

[Xinliang Liu]

Add maintainer and reviewer for hisilicon DRM driver.

v7: None.
v6: None.
v5: None.
v4:
- Add Chen Feng  as Designated reviewer.
v3: First version.

Signed-off-by: Xinliang Liu 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4978dc19a4d2..b94ac713916a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3774,6 +3774,16 @@ S:   Maintained
 F: drivers/gpu/drm/gma500
 F: include/drm/gma500*
 
+DRM DRIVERS FOR HISILICON
+M: Xinliang Liu 
+R: Xinwei Kong 
+R: Chen Feng 
+L: dri-de...@lists.freedesktop.org
+T: git git://github.com/xin3liang/linux.git
+S: Maintained
+F: drivers/gpu/drm/hisilicon
+F: Documentation/devicetree/bindings/display/hisilicon
+
 DRM DRIVERS FOR NVIDIA TEGRA
 M: Thierry Reding 
 M: Terje Bergström 
-- 
2.7.1

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

[PATCH v7 08/11] drm/hisilicon: Add designware dsi host driver

[Xinliang Liu]

Add DesignWare dsi host driver for hi6220 SoC.

v7: None.
v6: None.
v5: None.
v4: None.
v3: None.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Reviewed-by: Archit Taneja 
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 50 
 1 file changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index 1a930b77ec53..ea7711832959 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -80,6 +80,7 @@ struct dsi_hw_ctx {
 
 struct dw_dsi {
struct drm_encoder encoder;
+   struct mipi_dsi_host host;
struct drm_display_mode cur_mode;
struct dsi_hw_ctx *ctx;
struct mipi_phy_params phy;
@@ -654,6 +655,51 @@ static int dw_drm_encoder_init(struct device *dev,
return 0;
 }
 
+static int dsi_host_attach(struct mipi_dsi_host *host,
+  struct mipi_dsi_device *mdsi)
+{
+   struct dw_dsi *dsi = host_to_dsi(host);
+
+   if (mdsi->lanes < 1 || mdsi->lanes > 4) {
+   DRM_ERROR("dsi device params invalid\n");
+   return -EINVAL;
+   }
+
+   dsi->lanes = mdsi->lanes;
+   dsi->format = mdsi->format;
+   dsi->mode_flags = mdsi->mode_flags;
+
+   return 0;
+}
+
+static int dsi_host_detach(struct mipi_dsi_host *host,
+  struct mipi_dsi_device *mdsi)
+{
+   /* do nothing */
+   return 0;
+}
+
+static const struct mipi_dsi_host_ops dsi_host_ops = {
+   .attach = dsi_host_attach,
+   .detach = dsi_host_detach,
+};
+
+static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
+{
+   struct mipi_dsi_host *host = >host;
+   int ret;
+
+   host->dev = dev;
+   host->ops = _host_ops;
+   ret = mipi_dsi_host_register(host);
+   if (ret) {
+   DRM_ERROR("failed to register dsi host\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -665,6 +711,10 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;
 
+   ret = dsi_host_init(dev, dsi);
+   if (ret)
+   return ret;
+
return 0;
 }
 
-- 
2.7.1

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

[PATCH v7 03/11] drm/hisilicon: Add crtc driver for ADE

[Xinliang Liu]

Add crtc funcs and helper funcs for ADE.

v7:
- A few Regs define clean up and typo fixs.
v6:
- Cleanup reg-names dt parsing.
v5:
- Use syscon to access ADE media NOC QoS registers instead of directly
  writing registers.
- Use reset controller to reset ADE instead of directly writing registers.
v4: None.
v3:
- Make ade as the master driver.
- Use port to connect with encoder.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Reviewed-by: Archit Taneja 
---
 drivers/gpu/drm/hisilicon/kirin/Makefile|   3 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 230 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 462 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  12 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |   8 +
 5 files changed, 714 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c

diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
b/drivers/gpu/drm/hisilicon/kirin/Makefile
index cb346de47d48..2a61ab006ddb 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,3 +1,4 @@
-kirin-drm-y := kirin_drm_drv.o
+kirin-drm-y := kirin_drm_drv.o \
+  kirin_drm_ade.o
 
 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
new file mode 100644
index ..4cf281b7ed63
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -0,0 +1,230 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#ifndef __KIRIN_ADE_REG_H__
+#define __KIRIN_ADE_REG_H__
+
+/*
+ * ADE Registers
+ */
+#define MASK(x)(BIT(x) - 1)
+
+#define ADE_CTRL   0x0004
+#define FRM_END_START_OFST 0
+#define FRM_END_START_MASK MASK(2)
+#define AUTO_CLK_GATE_EN_OFST  0
+#define AUTO_CLK_GATE_EN   BIT(0)
+#define ADE_DISP_SRC_CFG   0x0018
+#define ADE_CTRL1  0x008C
+#define ADE_EN 0x0100
+#define ADE_DISABLE0
+#define ADE_ENABLE 1
+/* reset and reload regs */
+#define ADE_SOFT_RST_SEL(x)(0x0078 + (x) * 0x4)
+#define ADE_RELOAD_DIS(x)  (0x00AC + (x) * 0x4)
+#define RDMA_OFST  0
+#define CLIP_OFST  15
+#define SCL_OFST   21
+#define CTRAN_OFST 24
+#define OVLY_OFST  37 /* 32+5 */
+/* channel regs */
+#define RD_CH_CTRL(x)  (0x1004 + (x) * 0x80)
+#define RD_CH_ADDR(x)  (0x1008 + (x) * 0x80)
+#define RD_CH_SIZE(x)  (0x100C + (x) * 0x80)
+#define RD_CH_STRIDE(x)(0x1010 + (x) * 0x80)
+#define RD_CH_SPACE(x) (0x1014 + (x) * 0x80)
+#define RD_CH_EN(x)(0x1020 + (x) * 0x80)
+/* overlay regs */
+#define ADE_OVLY1_TRANS_CFG0x002C
+#define ADE_OVLY_CTL   0x0098
+#define ADE_OVLY_CH_XY0(x) (0x2004 + (x) * 4)
+#define ADE_OVLY_CH_XY1(x) (0x2024 + (x) * 4)
+#define ADE_OVLY_CH_CTL(x) (0x204C + (x) * 4)
+#define ADE_OVLY_OUTPUT_SIZE(x)(0x2070 + (x) * 8)
+#define OUTPUT_XSIZE_OFST  16
+#define ADE_OVLYX_CTL(x)   (0x209C + (x) * 4)
+#define CH_OVLY_SEL_OFST(x)((x) * 4)
+#define CH_OVLY_SEL_MASK   MASK(2)
+#define CH_OVLY_SEL_VAL(x) ((x) + 1)
+#define CH_ALP_MODE_OFST   0
+#define CH_ALP_SEL_OFST2
+#define CH_UNDER_ALP_SEL_OFST  4
+#define CH_EN_OFST 6
+#define CH_ALP_GBL_OFST15
+#define CH_SEL_OFST28
+/* ctran regs */
+#define ADE_CTRAN_DIS(x)   (0x5004 + (x) * 0x100)
+#define CTRAN_BYPASS_ON1
+#define CTRAN_BYPASS_OFF   0
+#define ADE_CTRAN_IMAGE_SIZE(x)(0x503C + (x) * 0x100)
+/* clip regs */
+#define ADE_CLIP_DISABLE(x)(0x6800 + (x) * 0x100)
+#define ADE_CLIP_SIZE0(x)  (0x6804 + (x) * 0x100)
+#define ADE_CLIP_SIZE1(x)  (0x6808 + (x) * 0x100)
+
+/*
+ * LDI Registers
+ */
+#define LDI_HRZ_CTRL0  0x7400
+#define HBP_OFST   20
+#define LDI_HRZ_CTRL1  0x7404
+#define LDI_VRT_CTRL0  0x7408
+#define VBP_OFST   

[PATCH v7 04/11] drm/hisilicon: Add plane driver for ADE

[Xinliang Liu]

Add plane funcs and helper funcs for ADE.

v7: None.
v6: None.
v5: None.
v4: None.
v3:
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 535 +++-
 1 file changed, 534 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index cfbea957297b..8a7cb5e04bf4 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -27,13 +27,23 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "kirin_drm_drv.h"
 #include "kirin_ade_reg.h"
 
+#define PRIMARY_CH ADE_CH1 /* primary plane */
+#define OUT_OVLY   ADE_OVLY2 /* output overlay compositor */
+#define ADE_DEBUG  1
+
 #define to_ade_crtc(crtc) \
container_of(crtc, struct ade_crtc, base)
 
+#define to_ade_plane(plane) \
+   container_of(plane, struct ade_plane, base)
+
 struct ade_hw_ctx {
void __iomem  *base;
struct regmap *noc_regmap;
@@ -52,11 +62,76 @@ struct ade_crtc {
u32 out_format;
 };
 
+struct ade_plane {
+   struct drm_plane base;
+   void *ctx;
+   u8 ch; /* channel */
+};
+
 struct ade_data {
struct ade_crtc acrtc;
+   struct ade_plane aplane[ADE_CH_NUM];
struct ade_hw_ctx ctx;
 };
 
+/* ade-format info: */
+struct ade_format {
+   u32 pixel_format;
+   enum ade_fb_format ade_format;
+};
+
+static const struct ade_format ade_formats[] = {
+   /* 16bpp RGB: */
+   { DRM_FORMAT_RGB565, ADE_RGB_565 },
+   { DRM_FORMAT_BGR565, ADE_BGR_565 },
+   /* 24bpp RGB: */
+   { DRM_FORMAT_RGB888, ADE_RGB_888 },
+   { DRM_FORMAT_BGR888, ADE_BGR_888 },
+   /* 32bpp [A]RGB: */
+   { DRM_FORMAT_XRGB, ADE_XRGB_ },
+   { DRM_FORMAT_XBGR, ADE_XBGR_ },
+   { DRM_FORMAT_RGBA, ADE_RGBA_ },
+   { DRM_FORMAT_BGRA, ADE_BGRA_ },
+   { DRM_FORMAT_ARGB, ADE_ARGB_ },
+   { DRM_FORMAT_ABGR, ADE_ABGR_ },
+};
+
+static const u32 channel_formats1[] = {
+   /* channel 1,2,3,4 */
+   DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888,
+   DRM_FORMAT_BGR888, DRM_FORMAT_XRGB, DRM_FORMAT_XBGR,
+   DRM_FORMAT_RGBA, DRM_FORMAT_BGRA, DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR
+};
+
+u32 ade_get_channel_formats(u8 ch, const u32 **formats)
+{
+   switch (ch) {
+   case ADE_CH1:
+   *formats = channel_formats1;
+   return ARRAY_SIZE(channel_formats1);
+   default:
+   DRM_ERROR("no this channel %d\n", ch);
+   *formats = NULL;
+   return 0;
+   }
+}
+
+/* convert from fourcc format to ade format */
+static u32 ade_get_format(u32 pixel_format)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(ade_formats); i++)
+   if (ade_formats[i].pixel_format == pixel_format)
+   return ade_formats[i].ade_format;
+
+   /* not found */
+   DRM_ERROR("Not found pixel format!!fourcc_format= %d\n",
+ pixel_format);
+   return ADE_FORMAT_UNSUPPORT;
+}
+
 static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
 {
u32 bit_ofst, reg_num;
@@ -89,7 +164,7 @@ static void ade_init(struct ade_hw_ctx *ctx)
/* clear overlay */
writel(0, base + ADE_OVLY1_TRANS_CFG);
writel(0, base + ADE_OVLY_CTL);
-   writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
+   writel(0, base + ADE_OVLYX_CTL(OUT_OVLY));
/* clear reset and reload regs */
writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
@@ -155,6 +230,10 @@ static void ade_ldi_set_mode(struct ade_crtc *acrtc,
   base + LDI_DSP_SIZE);
writel(plr_flags, base + LDI_PLR_CTRL);
 
+   /* set overlay compositor output size */
+   writel(((width - 1) << OUTPUT_XSIZE_OFST) | (height - 1),
+  base + ADE_OVLY_OUTPUT_SIZE(OUT_OVLY));
+
/* ctran6 setting */
writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
 /* the configured value is actual value - 1 */
@@ -229,6 +308,10 @@ static void ade_display_enable(struct ade_crtc *acrtc)
void __iomem *base = ctx->base;
u32 out_fmt = acrtc->out_format;
 
+   /* enable output overlay compositor */
+   writel(ADE_ENABLE, base + ADE_OVLYX_CTL(OUT_OVLY));
+   ade_update_reload_bit(base, OVLY_OFST + OUT_OVLY, 0);
+
/* display source setting */
writel(DISP_SRC_OVLY2, base + ADE_DISP_SRC_CFG);
 
@@ -242,6 +325,97 @@ static void ade_display_enable(struct ade_crtc *acrtc)
writel(DSI_PCLK_ON, base + LDI_HDMI_DSI_GT);
 }
 
+#if ADE_DEBUG
+static void ade_rdma_dump_regs(void __iomem *base, u32 ch)
+{
+   u32 

[PATCH v7 09/11] drm/hisilicon: Add support for external bridge

[Xinliang Liu]

Add support for external HDMI bridge.

v7: None.
v6: None.
v5: None.
v4: None.
v3:
- Fix a typo: s/exteranl/external.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Reviewed-by: Archit Taneja 
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 52 
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index ea7711832959..bfbc2159250d 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -80,6 +80,7 @@ struct dsi_hw_ctx {
 
 struct dw_dsi {
struct drm_encoder encoder;
+   struct drm_bridge *bridge;
struct mipi_dsi_host host;
struct drm_display_mode cur_mode;
struct dsi_hw_ctx *ctx;
@@ -700,6 +701,25 @@ static int dsi_host_init(struct device *dev, struct dw_dsi 
*dsi)
return 0;
 }
 
+static int dsi_bridge_init(struct drm_device *dev, struct dw_dsi *dsi)
+{
+   struct drm_encoder *encoder = >encoder;
+   struct drm_bridge *bridge = dsi->bridge;
+   int ret;
+
+   /* associate the bridge to dsi encoder */
+   encoder->bridge = bridge;
+   bridge->encoder = encoder;
+
+   ret = drm_bridge_attach(dev, bridge);
+   if (ret) {
+   DRM_ERROR("failed to attach external bridge\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -715,6 +735,10 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;
 
+   ret = dsi_bridge_init(drm_dev, dsi);
+   if (ret)
+   return ret;
+
return 0;
 }
 
@@ -731,8 +755,36 @@ static const struct component_ops dsi_ops = {
 static int dsi_parse_dt(struct platform_device *pdev, struct dw_dsi *dsi)
 {
struct dsi_hw_ctx *ctx = dsi->ctx;
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *endpoint, *bridge_node;
+   struct drm_bridge *bridge;
struct resource *res;
 
+   /*
+* Get the endpoint node. In our case, dsi has one output port1
+* to which the external HDMI bridge is connected.
+*/
+   endpoint = of_graph_get_endpoint_by_regs(np, 1, -1);
+   if (!endpoint) {
+   DRM_ERROR("no valid endpoint node\n");
+   return -ENODEV;
+   }
+   of_node_put(endpoint);
+
+   bridge_node = of_graph_get_remote_port_parent(endpoint);
+   if (!bridge_node) {
+   DRM_ERROR("no valid bridge node\n");
+   return -ENODEV;
+   }
+   of_node_put(bridge_node);
+
+   bridge = of_drm_find_bridge(bridge_node);
+   if (!bridge) {
+   DRM_INFO("wait for external HDMI bridge driver.\n");
+   return -EPROBE_DEFER;
+   }
+   dsi->bridge = bridge;
+
ctx->pclk = devm_clk_get(>dev, "pclk");
if (IS_ERR(ctx->pclk)) {
DRM_ERROR("failed to get pclk clock\n");
-- 
2.7.1

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

[PATCH v7 06/11] drm/hisilicon: Add cma fbdev and hotplug

[Xinliang Liu]

Add cma Fbdev, Fbdev is legency and optional, you can enable/disable it by
configuring DRM_FBDEV_EMULATION.
Add hotplug.

v7: None.
v6: None.
v5: None.
v4: None.
v3: None.
v2:
- Use CONFIG_DRM_FBDEV_EMULATION instead of CONFIG_DRM_HISI_FBDEV.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 34 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  3 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 2a899c5bb14e..e102c9e1e7b2 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "kirin_drm_drv.h"
 
@@ -32,6 +33,13 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+   if (priv->fbdev) {
+   drm_fbdev_cma_fini(priv->fbdev);
+   priv->fbdev = NULL;
+   }
+#endif
+   drm_kms_helper_poll_fini(dev);
drm_vblank_cleanup(dev);
dc_ops->cleanup(dev);
drm_mode_config_cleanup(dev);
@@ -41,8 +49,28 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
return 0;
 }
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
+{
+   struct kirin_drm_private *priv = dev->dev_private;
+
+   if (priv->fbdev) {
+   drm_fbdev_cma_hotplug_event(priv->fbdev);
+   } else {
+   priv->fbdev = drm_fbdev_cma_init(dev, 32,
+   dev->mode_config.num_crtc,
+   dev->mode_config.num_connector);
+   if (IS_ERR(priv->fbdev))
+   priv->fbdev = NULL;
+   }
+}
+#endif
+
 static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+   .output_poll_changed = kirin_fbdev_output_poll_changed,
+#endif
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
@@ -98,6 +126,12 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* reset all the states of crtc/plane/encoder/connector */
drm_mode_config_reset(dev);
 
+   /* init kms poll for handling hpd */
+   drm_kms_helper_poll_init(dev);
+
+   /* force detection after connectors init */
+   (void)drm_helper_hpd_irq_event(dev);
+
return 0;
 
 err_unbind_all:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 5a05ad6a81db..1a07caf8e7f4 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -21,6 +21,9 @@ struct kirin_dc_ops {
 
 struct kirin_drm_private {
struct drm_crtc *crtc[MAX_CRTC];
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+   struct drm_fbdev_cma *fbdev;
+#endif
 };
 
 extern const struct kirin_dc_ops ade_dc_ops;
-- 
2.7.1

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

[PATCH v7 02/11] drm/hisilicon: Add hisilicon kirin drm master driver

[Xinliang Liu]

Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
Add dumb buffer feature.
Add prime dmabuf feature.

v7:
- Add config.mutex protection when accessing mode_config.connector_list.
- Clean up match data getting.
v6: None.
v5: None.
v4: None.
v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Replace drm_platform_init, load, unload implementation.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
---
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/hisilicon/Kconfig   |   5 +
 drivers/gpu/drm/hisilicon/Makefile  |   5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig |   9 +
 drivers/gpu/drm/hisilicon/kirin/Makefile|   3 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 309 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
 8 files changed, 354 insertions(+)
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b50ae60f5f50..f5c5656e2547 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -277,3 +277,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"
 
 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/hisilicon/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766dec6a8d..60554832079c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -74,3 +74,4 @@ obj-y += panel/
 obj-y  += bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-y  += hisilicon/
diff --git a/drivers/gpu/drm/hisilicon/Kconfig 
b/drivers/gpu/drm/hisilicon/Kconfig
new file mode 100644
index ..558c61b1b8e8
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+#
+# hisilicon drm device configuration.
+# Please keep this list sorted alphabetically
+
+source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
diff --git a/drivers/gpu/drm/hisilicon/Makefile 
b/drivers/gpu/drm/hisilicon/Makefile
new file mode 100644
index ..e3f6d493c996
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for hisilicon drm drivers.
+# Please keep this list sorted alphabetically
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig 
b/drivers/gpu/drm/hisilicon/kirin/Kconfig
new file mode 100644
index ..3ac4b8edeac1
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -0,0 +1,9 @@
+config DRM_HISI_KIRIN
+   tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   help
+ Choose this option if you have a hisilicon Kirin chipsets(hi6220).
+ If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
b/drivers/gpu/drm/hisilicon/kirin/Makefile
new file mode 100644
index ..cb346de47d48
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -0,0 +1,3 @@
+kirin-drm-y := kirin_drm_drv.o
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
new file mode 100644
index ..976c9b1a3fd3
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -0,0 +1,309 @@
+/*
+ * Hisilicon Kirin SoCs drm master driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ * Xinliang Liu 
+ * Xinliang Liu 
+ * Xinwei Kong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "kirin_drm_drv.h"
+
+static struct kirin_dc_ops *dc_ops;
+
+static int kirin_drm_kms_cleanup(struct drm_device *dev)
+{
+   dc_ops->cleanup(dev);
+   drm_mode_config_cleanup(dev);
+
+   return 0;
+}
+
+static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
+   .fb_create = drm_fb_cma_create,
+   .atomic_check = 

[PATCH v7 01/11] drm/hisilicon: Add device tree binding for hi6220 display subsystem

[Xinliang Liu]

Add ADE display controller binding doc.
Add DesignWare DSI Host Controller v1.20a binding doc.

v7: Acked by Rob Herring.
v6:
- Cleanup values part of reg and clocks properties.
- Change "pclk_dsi" clock name to "pclk".
v5:
- Remove endpoint unit address of dsi output port.
- Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon.
- Add "resets" property for ADE reset.
v4:
- Describe more specific of clocks and ports.
- Fix indentation.
v3:
- Make ade as the drm master node.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
v2:
- Move dt binding docs to bindings/display/hisilicon directory.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Acked-by: Rob Herring 
---
 .../bindings/display/hisilicon/dw-dsi.txt  | 72 ++
 .../bindings/display/hisilicon/hisi-ade.txt| 64 +++
 2 files changed, 136 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt

diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt 
b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
new file mode 100644
index ..d270bfe4e4e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
@@ -0,0 +1,72 @@
+Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
+
+A DSI Host Controller resides in the middle of display controller and external
+HDMI converter or panel.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-dsi".
+- reg: physical base address and length of dsi controller's registers.
+- clocks: contains APB clock phandle + clock-specifier pair.
+- clock-names: should be "pclk".
+- ports: contains DSI controller input and output sub port.
+  The input port connects to ADE output port with the reg value "0".
+  The output port with the reg value "1", it could connect to panel or
+  any other bridge endpoints.
+  See Documentation/devicetree/bindings/graph.txt for more device graph info.
+
+A example of HiKey board hi6220 SoC and board specific DT entry:
+Example:
+
+SoC specific:
+   dsi: dsi@f4107800 {
+   compatible = "hisilicon,hi6220-dsi";
+   reg = <0x0 0xf4107800 0x0 0x100>;
+   clocks = <_ctrl  HI6220_DSI_PCLK>;
+   clock-names = "pclk";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* 0 for input port */
+   port@0 {
+   reg = <0>;
+   dsi_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+
+
+Board specific:
+{
+   status = "ok";
+
+   ports {
+   /* 1 for output port */
+   port@1 {
+   reg = <1>;
+
+   dsi_out0: endpoint@0 {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+{
+   ...
+
+   adv7533: adv7533@39 {
+   ...
+
+   port {
+   adv7533_in: endpoint {
+   remote-endpoint = <_out0>;
+   };
+   };
+   };
+   };
+
diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt 
b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
new file mode 100644
index ..38dc9d60eef8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
@@ -0,0 +1,64 @@
+Device-Tree bindings for hisilicon ADE display controller driver
+
+ADE (Advanced Display Engine) is the display controller which grab image
+data from memory, do composition, do post image processing, generate RGB
+timing stream and transfer to DSI.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-ade".
+- reg: physical base address and length of the ADE controller's registers.
+- hisilicon,noc-syscon: ADE NOC QoS syscon.
+- resets: The ADE reset controller node.
+- interrupt: the ldi vblank interrupt number used.
+- clocks: a list of phandle + clock-specifier pairs, one for each entry
+  in clock-names.
+- clock-names: should contain:
+  "clk_ade_core" for the ADE core clock.
+  "clk_codec_jpeg" for the media NOC QoS clock, which use the same clock with
+  jpeg codec.
+  "clk_ade_pix" for the ADE pixel clok.
+- assigned-clocks: Should contain "clk_ade_core" and "clk_codec_jpeg" 

[PATCH v7 00/11] Add DRM Driver for HiSilicon Kirin hi6220 SoC

[Xinliang Liu]

This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC.
Current testing and support board is Hikey board which is one of Linaro
96boards. It is an arm64 open source board. For more information about
this board, please access https://www.96boards.org.

Hardware Detail
---
  The display subsystem of Hi6220 SoC is shown as bellow:
 +-+   +--+ +-+ +-+
 | |   |  | | | | | 
 | FB  |-->|   ADE|>| DSI |>|   External  |
 | |   |  | | | |  HDMI/panel |
 +-+   +--+ +-+ +-+

- ADE(Advanced Display Engine) is the display controller. It contains 7
channels, 3 overlay compositors and a LDI.
  - A channel looks like: DMA-->clip-->scale-->ctrans(or called csc).
  - Overlay compositor is response to compose planes which come from 7
  channels and pass composed image to LDI.
  - LDI is response to generate timings and RGB data stream.
- DSI converts the RGB data stream from ADE to DSI packets.
- External HDMI/panel module is connected with DSI bus. Now Hikey use a
  ADI's ADV7533 external HDMI chip.

Change History
-
Changes in v7:
- Add config.mutex protection when accessing mode_config.connector_list.
- Clean up match data getting of kirin_drm_drv.c.
- A few Regs define clean up and typo fixs for ADE crtc and DSI encoder
  driver.
- Fix vblank irq flag "DRIVER_IRQF_SHARED" to "IRQF_SHARED".
Changes in v6:
- Cleanup values part of reg and clocks relevant properties.
- Change "pclk_dsi" clock name to "pclk".

Changes in v5:
- Remove endpoint unit address of dsi output port.
- Use syscon to access ADE media NOC QoS registers instread of directly
  writing registers.
- Use reset controller to reset ADE instead of directly writing registers.

Changes in v4:
- Describe more specific of clocks and ports of binding docs.
- Fix indentation of binding docs.

Changes in v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Make ade as the drm master node.
- Replace drm_platform_init, load, unload implementation.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relevant nodes.
- Rename hisi_drm_dsi.c to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup on regs and code.

Changes in v2:
- Remove abtraction layer of plane/crtc/encoder/connector.
- Refactor atomic implementation according to Daniel Vetter's guides:
http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
http://blog.ffwll.ch/2015/09/xdc-2015-atomic-modesetting-for-drivers.html
http://blog.ffwll.ch/2015/08/atomic-modesetting-design-overview.html
- Use bridge instead of slave encoder to connect external HDMI.
- Move dt binding docs to bindings/display/hisilicon directory.

Xinliang Liu (11):
  drm/hisilicon: Add device tree binding for hi6220 display subsystem
  drm/hisilicon: Add hisilicon kirin drm master driver
  drm/hisilicon: Add crtc driver for ADE
  drm/hisilicon: Add plane driver for ADE
  drm/hisilicon: Add vblank driver for ADE
  drm/hisilicon: Add cma fbdev and hotplug
  drm/hisilicon: Add designware dsi encoder driver
  drm/hisilicon: Add designware dsi host driver
  drm/hisilicon: Add support for external bridge
  MAINTAINERS: Add maintainer for hisilicon DRM driver
  arm64: dts: hisilicon: Add display subsystem DT nodes for hi6220

 .../bindings/display/hisilicon/dw-dsi.txt  |   72 ++
 .../bindings/display/hisilicon/hisi-ade.txt|   64 ++
 MAINTAINERS|   10 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   40 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |   55 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/hisilicon/Kconfig  |5 +
 drivers/gpu/drm/hisilicon/Makefile |5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig|   10 +
 drivers/gpu/drm/hisilicon/kirin/Makefile   |5 +
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c   |  857 
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h   |  103 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h|  230 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c| 1057 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  367 +++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h|   31 +
 17 files changed, 2914 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 

Re: Kernel docs: muddying the waters a bit

[Johannes Stezenbach]

On Fri, Mar 04, 2016 at 10:29:08AM +0200, Jani Nikula wrote:
> On Fri, 04 Mar 2016, Mauro Carvalho Chehab  wrote:
> >
> > If, on the other hand, we decide to use RST, we'll very likely need to
> > patch it to fulfill our needs in order to add proper table support.
> > I've no idea how easy/difficult would be to do that, nor if Sphinx
> > upstream would accept such changes.
> >
> > So, at the end of the day, we may end by having to carry on our own
> > version of Sphinx inside our tree, with doesn't sound good, specially
> > since it is not just a script, but a package with hundreds of
> > files.
> 
> If we end up having to modify Sphinx, it has a powerful extension
> mechanism for this. We wouldn't have to worry about getting it merged to
> Sphinx upstream, and we wouldn't have to carry a local version of all of
> Sphinx. (In fact, the extension mechanism provides a future path for
> doing kernel-doc within Sphinx instead of as a preprocessing step.)
> 
> I know none of this alleviates your concerns with table supports right
> now. I'll try to have a look at that a bit more.

FWIW, I think table formatting in Sphinx works via style sheets.
The mechanism is documented in the Python docutils docs that
Sphinx is built upon.
Basically you use the "class" or "role" directive and define
the corresponding CSS or LaTeX (or rst2pdf) style.

Here is one example (using a custom "cssclass" role):
https://pythonhosted.org/sphinxjp.themes.basicstrap/sample.html

Directives (especially role and class):
http://www.sphinx-doc.org/en/stable/rest.html#directives

LaTeX styling:
http://docutils.readthedocs.org/en/sphinx-docs/user/latex.html#custom-interpreted-text-roles


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

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Fri, 04 Mar 2016, Mauro Carvalho Chehab  wrote:
> Em Thu, 03 Mar 2016 15:23:23 -0800
> Keith Packard  escreveu:
>
>> Mauro Carvalho Chehab  writes:
>> 
>> > On my tests, Sphinix seemed too limited to format tables. Asciidoc
>> > produced an output that worked better.  
>> 
>> Yes, asciidoc has much more flexibility in table formatting, including
>> the ability to control text layout within cells and full control over
>> borders.
>> 
>> However, I think asciidoc has two serious problems:
>> 
>>   1) the python version (asciidoc) appears to have been abandoned in
>>  favor of the ruby version. 
>> 
>>   2) It really is just a docbook pre-processor. Native html/latex output
>>  is poorly supported at best, and exposes only a small subset of the
>>  full capabilities of the input language.
>> 
>> As such, we would have to commit to using the ruby version and either
>> committing to fixing the native html output backend or continuing to use
>> the rest of the docbook toolchain.
>> 
>> We could insist on using the python version, of course. I spent a bit of
>> time hacking that up to add 'real' support for a table-of-contents in
>> the native HTML backend and it looks like getting those changes
>> upstreamed would be reasonably straightforward. However, we'd end up
>> 'owning' the code, and I'm not sure we want to.
>
> I'm a way more concerned about using a tool that fulfill our needs
> than to look for something that won't use the docbook toolchain or
> require to install ruby.

I think you meant that to be the other way round, or I fail at parsing
you. ;)

> In the case of Docbook, we know it works and we know already its
> issues. Please correct me if I'm wrong, but the big problem we
> have is not due to the DocBook toolchain, but due to the lack of
> features at the kernel-doc script. Also, xmlto is already installed
> by the ones that build the kernel docs. So, keeping use it won't
> require to install a weird toolchain by hand.

I think kernel-doc is just a small part of the puzzle. It's a problem,
but a small one at that, and we've already made it output asciidoc, rst
and docbook as part of this exercise. For real, as in code, not as in
talk.

The reasons I'm involved in this is that I want to make writing
documentation and rich kernel-doc comments easier (using lightweight
markup) and I want to make building the documentation easier (using a
straightforward toolchain with not too many dependencies). I'm hoping
the former makes writing documentation more attractive and the latter
keeps the documentation and the toolchain in a better shape through
having more people actually build the documentation.

IMHO docbook is problematic because the toolchain gets too long and
fragile. You need plenty of tools installed to build the documentation,
it's fussy to get working, and people just won't. Like code,
documentation bitrots too when it's not used. The documentation build is
broken too often. Debugging formatting issues through the entire
pipeline gets hard; I already faced some of this when playing with the
kernel-doc->asciidoc->docbook->html chain.

In short, I don't think the docbook toolchain fills all of our needs
either.

> So, to be frank, it doesn't scary me to use either pyhton or
> ruby script + docbook.
>
> Of course, having to own the code has a cost that should be evaluated.
>
> If, on the other hand, we decide to use RST, we'll very likely need to
> patch it to fulfill our needs in order to add proper table support.
> I've no idea how easy/difficult would be to do that, nor if Sphinx
> upstream would accept such changes.
>
> So, at the end of the day, we may end by having to carry on our own
> version of Sphinx inside our tree, with doesn't sound good, specially
> since it is not just a script, but a package with hundreds of
> files.

If we end up having to modify Sphinx, it has a powerful extension
mechanism for this. We wouldn't have to worry about getting it merged to
Sphinx upstream, and we wouldn't have to carry a local version of all of
Sphinx. (In fact, the extension mechanism provides a future path for
doing kernel-doc within Sphinx instead of as a preprocessing step.)

I know none of this alleviates your concerns with table supports right
now. I'll try to have a look at that a bit more.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html