RE: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

2016-02-05 Thread Mike Leach 
Hi,

I think a quick clarification of the ARM hardware STM architecture may be of 
value here.

The ARM hardware STM, when implemented as recommend in a hardware design, the 
master IDs are not under driver control, but have a hardwire association with 
source devices in the system. The master IDs are hardwired to individual cores 
and core security states, and there could be other IDs associated with hardware 
trace sources requiring output via the hardware STM. (an example of this is the 
ARM Juno development board).

Therefore in multi-core systems many masters may be associated with a single 
software STM stream. A user-space application running on Core 1, may have a 
master ID of 0x11 in the STPv2 trace stream, but if this application is context 
switched and later continues running on Core 2, then master ID could change to 
0x21.  Masters identify a hardware source in this scheme, the precise values 
used will be implementation dependent.

So the number of masters "available to the software" depends on your 
interpretation of the phrase.
If you mean "master IDs on which software trace will appear" then that will be 
many - it depends on which core is running the application. However as 
described above, this is not predictable by any decoder, and the master set 
used may not be contiguous.
If you mean "master IDs selectable/allocated by the driver" then that will be 0 
- the driver has no control, and possibly no knowledge of which master is 
associated with the current execution context. (this is of course system 
dependent - it may well be possible to have some configuration database 
associating cores with hardware IDs, but this will be implementation and board 
support dependant).

Therefore, there is a requirement to tell both the user-space STM client and 
decoder that not only is master ID management not needed - it is in fact not 
possible and the key to identify the software source for a given STM packet is 
the channel alone. In addition we have a nominal single Master ID "available to 
the software", to satisfy the requirements of the generic ST module API.

So on Juno for example, while we do have 128 masters, each with 65536 channels, 
the master allocation is not visible to system software - each core sees a 
single master with 65536 channels. Therefore differentiation between software 
sources in the STM trace is by channel number allocations only.

Best Regards

Mike.


Mike Leach   +44 (0)1254 893911 (Direct)
Principal Engineer   +44 (0)1254 893900 (Main)
Arm Blackburn Design Centre  +44 (0)1254 893901 (Fax)
Belthorn House
Walker Rdmailto:mike.le...@arm.com
Guide
Blackburn
BB1 2QE



> -Original Message-
> From: Alexander Shishkin [mailto:alexander.shish...@linux.intel.com]
> Sent: 05 February 2016 12:52
> To: Chunyan Zhang; mathieu.poir...@linaro.org
> Cc: r...@kernel.org; broo...@kernel.org; prat...@codeaurora.org;
> nicolas.gu...@st.com; cor...@lwn.net; Mark Rutland; Mike Leach;
> t...@ti.com; Al Grant; zhang.l...@gmail.com; linux-ker...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
> d...@vger.kernel.org
> Subject: Re: [PATCH V2 3/6] stm class: provision for statically assigned
> masterIDs
>
> Chunyan Zhang  writes:
>
> > From: Mathieu Poirier 
> >
> > Some architecture like ARM assign masterIDs statically at the HW design
> > phase, making masterID manipulation in the generic STM core irrelevant.
> >
> > This patch adds a new 'mstatic' flag to struct stm_data that tells the
> > core that this specific STM device doesn't need explicit masterID
> > management.
>
> So why do we need this patch? If your STM only has master 42 allocated
> for software sources, simply set sw_start = 42, sw_end = 42 and you're
> good to go, software will have exactly one channel to choose from. See
> also the comment from :
>
>  * @sw_start:   first STP master available to software
>  * @sw_end: last STP master available to software
>
> particularly the "available to software" part. Any other kinds of
> masters the STM class code doesn't care about (yet).
>
> > In the core sw_start/end of masterID are set to '1',
> > i.e there is only one masterID to deal with.
>
> This is also a completely arbitrary and unnecessary requirement. Again,
> you can set both to 42 and it will still work.
>
> > Also this patch depends on [1], so that the number of masterID
> > is '1' too.
> >
> > Finally the lower and upper bound for masterIDs as presented
> > in ($SYSFS)/class/stm/XYZ.stm/masters and
> > ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
> > are set to '-1'.  That way users can't confuse them with
> > architecture where masterID management is required (where any
> >

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

2016-02-05 Thread Fu Wei 
On 5 February 2016 at 22:42, Guenter Roeck  wrote:
> On 02/05/2016 01:51 AM, Fu Wei wrote:
>>
>> Hi Guenter,
>>
>> On 4 February 2016 at 13:17, Guenter Roeck  wrote:
>>>
>>> On 02/03/2016 03:00 PM, Fu Wei wrote:


 On 4 February 2016 at 02:45, Timur Tabi  wrote:
>
>
> Fu Wei wrote:
>>
>>
>>
>> As you know I have made the pre-timeout support patch, If people like
>> it, i am happy to go on upstream it separately.
>>
>> If we want to use pre-timeout here, user only can use get_pretimeout
>> and disable panic by setting pretimeout to 0
>> but user can not really set pretimeout, because "pre-timeout  ==
>> timeout / 2 (always)".
>> if user want to change pretimeout, he/she has to set_time instead.
>
>
>
>
> Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
> entry should be removed and just use panic_enabled.
>>>
>>>
>>>
>>> Agreed.
>>
>>
>> np, will do
>>


 NP, will update this patchset like that ,  thanks :-)

>>>
>>> Also, if panic is enabled, the timeout needs to be adjusted accordingly
>>> (to only panic after the entire timeout period has expired, not after
>>> half of it). We can not panic the system after timeout / 2.
>>
>>
>> OK, my thought is
>>
>> if panic is enabled :
>> |WOR---WS0WOR---WS1
>> |--timeout--(panic)--timeout-reset
>>
>> if panic is disabled .
>> |WOR---WS0WOR---WS1
>> |-timeout-reset
>>
>>   panic_enabled only can be configured when module is loaded by module
>> parameter
>>
>> But user should know that max_timeout(panic_enable) =
>> max_timeout(panic_disable) / 2
>>
>
> That means you'll have to update max_timeout accordingly.

panic_enabled only can be configured when module is loaded, so we
don't need to update it.

max_timeout will only be set up in the init stage.

Does it make sense ? :-)

>
>>>
>>> I am not too happy with the parameter name (panic_enabled). How about
>>> "action", to match machzwd ?
>>
>>
>> yes, makes sense. Maybe we can do something  like this:
>>
>> /*
>>   * action refers to action taken when watchdog gets WS0
>>   * 0 = SKIP
>>   * 1 = PANIC
>>   * defaults to SKIP (0)
>>   */
>> static int action;
>> module_param(action, int, 0);
>> MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
>> "0 = SKIP(*)  1 = PANIC");
>>
> Yes, though I would suggest to use lower case letters.

yes,  NP, will do , Thanks :-)

>
> Thanks,
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
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 3/6] stm class: provision for statically assigned masterIDs

2016-02-05 Thread Mathieu Poirier 
On 5 February 2016 at 05:52, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> From: Mathieu Poirier 
>>
>> Some architecture like ARM assign masterIDs statically at the HW design
>> phase, making masterID manipulation in the generic STM core irrelevant.
>>
>> This patch adds a new 'mstatic' flag to struct stm_data that tells the
>> core that this specific STM device doesn't need explicit masterID
>> management.
>
> So why do we need this patch? If your STM only has master 42 allocated
> for software sources, simply set sw_start = 42, sw_end = 42 and you're
> good to go, software will have exactly one channel to choose from. See
> also the comment from :

On ARM each source, i.e entity capable of accessing STM channels, has
a different master ID set in HW.  We can't assume the IDs are
contiguous and from a SW point of view there is no way to probe the
values.

>
>  * @sw_start:   first STP master available to software
>  * @sw_end: last STP master available to software
>
> particularly the "available to software" part. Any other kinds of
> masters the STM class code doesn't care about (yet).
>
>> In the core sw_start/end of masterID are set to '1',
>> i.e there is only one masterID to deal with.
>
> This is also a completely arbitrary and unnecessary requirement. Again,
> you can set both to 42 and it will still work.

True - any value will do. The important thing to remember is that on
ARM, there is only one masterID channel (from an STM core point of
view).  But we could also proceed differently, see below for more
details.

>
>> Also this patch depends on [1], so that the number of masterID
>> is '1' too.
>>
>> Finally the lower and upper bound for masterIDs as presented
>> in ($SYSFS)/class/stm/XYZ.stm/masters and
>> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
>> are set to '-1'.  That way users can't confuse them with
>> architecture where masterID management is required (where any
>> other value would be valid).
>
> Why is this a good idea? Having the actual master there will allow
> software to know what it is and also tell the decoding side what it is
> (assuming you have more than one source in the STP stream, it might not
> be easy to figure out, unless you know it in advance).

In the ARM world masterIDs are irrelevant so why bother with them?
Writing a '-1' simply highlight this reality.

Another way of approaching the problem would be to change sw_start/end
to a bitfield that represent the valid masterIDs but in my opinion, it
is a lot of code churn for information that isn't used outside of the
decoder.

Thanks,
Mathieu

>
> I don't see how one master statically assigned to software sources is
> different from two masters or 32 masters. And I don't see any benefit of
> hiding the master id from userspace. Am I missing something?
>
> Regards,
> --
> Alex
--
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 v4 1/3] rtc: Add functions to set and read rtc offset

2016-02-05 Thread Joshua Clayton 
A number of rtc devices, such as the NXP pcf2123 include a facility
to adjust the clock in order to compensate for temperature or a
crystal, capacitor, etc, that results in the rtc clock not running
at exactly 32.768 kHz.

Data sheets I have seen refer to this as a clock offset, and measure it
in parts per million, however they often reference ppm to 2 digits of
precision, which makes integer ppm less than ideal.

We use parts per billion, which more than covers the precision needed
and works nicely within 32 bits

Signed-off-by: Joshua Clayton 
---
 drivers/rtc/interface.c | 54 +
 include/linux/rtc.h |  4 
 2 files changed, 58 insertions(+)

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 5836751..9ef5f6f 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -939,4 +939,58 @@ void rtc_timer_cancel(struct rtc_device *rtc, struct 
rtc_timer *timer)
mutex_unlock(>ops_lock);
 }
 
+/**
+ * rtc_read_offset - Read the amount of rtc offset in parts per billion
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * see below for details.
+ *
+ * Kernel interface to read rtc clock offset
+ * Returns 0 on success, or a negative number on error.
+ * If read_offset() is not implemented for the rtc, return -EINVAL
+ */
+int rtc_read_offset(struct rtc_device *rtc, long *offset)
+{
+   int ret;
+
+   if (!rtc->ops)
+   return -ENODEV;
+
+   if (!rtc->ops->read_offset)
+   return -EINVAL;
+
+   mutex_lock(>ops_lock);
+   ret = rtc->ops->read_offset(rtc->dev.parent, offset);
+   mutex_unlock(>ops_lock);
+   return ret;
+}
 
+/**
+ * rtc_set_offset - Adjusts the duration of the average second
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * Some rtc's allow an adjustment to the average duration of a second
+ * to compensate for differences in the actual clock rate due to temperature,
+ * the crystal, capacitor, etc.
+ *
+ * Kernel interface to adjust an rtc clock offset.
+ * Return 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return -EINVAL
+ */
+int rtc_set_offset(struct rtc_device *rtc, long offset)
+{
+   int ret;
+
+   if (!rtc->ops)
+   return -ENODEV;
+
+   if (!rtc->ops->set_offset)
+   return -EINVAL;
+
+   mutex_lock(>ops_lock);
+   ret = rtc->ops->set_offset(rtc->dev.parent, offset);
+   mutex_unlock(>ops_lock);
+   return ret;
+}
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 3359f04..b693ada 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -89,6 +89,8 @@ struct rtc_class_ops {
int (*set_mmss)(struct device *, unsigned long secs);
int (*read_callback)(struct device *, int data);
int (*alarm_irq_enable)(struct device *, unsigned int enabled);
+   int (*read_offset)(struct device *, long *offset);
+   int (*set_offset)(struct device *, long offset);
 };
 
 #define RTC_DEVICE_NAME_SIZE 20
@@ -208,6 +210,8 @@ void rtc_timer_init(struct rtc_timer *timer, void (*f)(void 
*p), void *data);
 int rtc_timer_start(struct rtc_device *rtc, struct rtc_timer *timer,
ktime_t expires, ktime_t period);
 void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer);
+int rtc_read_offset(struct rtc_device *rtc, long *offset);
+int rtc_set_offset(struct rtc_device *rtc, long offset);
 void rtc_timer_do_work(struct work_struct *work);
 
 static inline bool is_leap_year(unsigned int year)
-- 
2.5.0

--
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 v16 3/6] ARM: socfpga: add bindings document for fpga bridge drivers

2016-02-05 Thread atull 
From: Alan Tull 

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

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 {
+   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"
+- 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 {
+   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

[PATCH v16 1/6] fpga: add bindings document for fpga region

2016-02-05 Thread atull 
From: Alan Tull 

New bindings document for FPGA Region to support programming
FPGA's under Device Tree control

Signed-off-by: Alan Tull 
Signed-off-by: Moritz Fischer 
---
v9:  initial version added to this patchset
v10: s/fpga/FPGA/g
 replace DT overlay example with slightly more complicated example
 move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Changed to use FPGA bridges framework instead of resets
 for bridges.
v13: bridge@0xff2 -> bridge@ff20, etc
 Leave out directly talking about overlays
 Remove regs and clocks directly under simple-fpga-bus in example
 Use common "firmware-name" binding instead of "fpga-firmware"
v14: Use firmware-name in bindings description
 Call it FPGA Area
 Remove bindings that specify FPGA Manager and FPGA Bridges
v15: Cleanup as per Rob's comments
 Combine usage doc with bindings document
 Document as being Altera specific
 Additions and changes to add FPGA Bus
v16: Reworked to document FPGA Regions
 rename altera-fpga-bus-fpga-area.txt -> fpga-region.txt
 Remove references that made it sound exclusive to Altera
 Remove altr, prefix from fpga-bus and fpga-area compatible strings
 Added Moritz' usage example with Xilinx
 Cleaned up unit addresses
---
 .../devicetree/bindings/fpga/fpga-region.txt   |  348 
 1 file changed, 348 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt

diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt 
b/Documentation/devicetree/bindings/fpga/fpga-region.txt
new file mode 100644
index 000..ccd7127
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -0,0 +1,348 @@
+FPGA Region Device Tree Binding
+
+Alan Tull 2016
+
+ CONTENTS
+ - Introduction
+ - Terminology
+ - Overview
+ - Constraints
+ - FPGA Region
+ - Supported Use Models
+ - Sequence
+ - Device Tree Examples
+
+
+Introduction
+
+
+FPGA Regions are introduced as a way to solve the problem of how to program an
+FPGA under an operating system and have the new hardware show up in the device
+tree.  By adding these bindings to the Device Tree, a system can have the
+information needed to program the FPGA and add the desired hardware, and also
+the information about the devices to be added to the Device Tree once the
+programming has succeeded.
+
+
+Terminology
+===
+
+Full Reconfiguration
+ * The entire FPGA is programmed.
+
+Partial Reconfiguration (PR)
+Partial Reconfiguration Region (PRR)
+ * The FPGA is divided into regions.  Each of these regions can be programmed
+   while the rest of the FPGA is not affected.  Not all FPGA's support this.
+ * PRR's may vary in size and in the connections at their edge.  The image
+   that is loaded into a PRR must fit and must use a subset of the region's
+   connections.
+
+Base image
+ * An FPGA image that is designed to do full reconfiguration of the FPGA.
+ * A base image may set up a set of regions to allow for partial
+   reconfiguration.
+
+Persona
+ * An FPGA image that is designed to be loaded into a PRR.  There may be
+   any number of personas designed to fit into a PRR, but only one at at time
+   may be loaded.
+ * A persona may create more regions.
+
+FPGA Manager & FPGA Manager Framework
+ * An FPGA Manager is a hardware block that programs an FPGA under the control
+   of a host processor.
+ * The FPGA Manager Framework provides drivers and functions to program an
+   FPGA.
+
+FPGA Bridge Framework
+ * Provides drivers and functions to control bridges that enable/disable
+   data to the FPGA.
+ * FPGA Bridges should be disabled while the FPGA is being programmed to
+   prevent spurious data on the bus.
+ * FPGA Bridges may not be needed in implementations where the FPGA Manager
+   handles this.
+
+Freeze Blocks
+ * Freeze Blocks function as FPGA Bridges within the FPGA fabric.  In the case
+   of PR, the buses from the processor are split within the FPGA.  Each PR
+   region gets its own split of the buses, protected by an independently
+   controlled Freeze Block.  Several busses may be connected to a single
+   PR region; a Freeze Block controls the traffic of all these busses
+   together.
+
+
+Overview
+
+
+This binding introduces the FPGA Region.
+
+An FPGA Region references the devices needed to be able to program an FPGA
+device.  The base FPGA Region in the device tree is required to include a
+property with a phandle to an FPGA Manager.  This region may also contain a
+property that has a list of FPGA Bridge phandles, if needed.  Child FPGA 
Regions
+inherit the parent's FPGA Manager but specify their own bridges.
+
+The base FPGA Region supports full reconfiguration of the FPGA device.  If the
+FPGA image loaded contains the logic that creates a set of Partial

[PATCH v4 2/3] rtc: implement a sysfs interface for clock offset

2016-02-05 Thread Joshua Clayton 
clock offset may be set and read in decimal parts per billion
attribute is /sys/class/rtc/rtcN/offset
The attribute is only visible for rtcs that have set_offset implemented.

Signed-off-by: Joshua Clayton 
---
 Documentation/rtc.txt   |  6 ++
 drivers/rtc/rtc-sysfs.c | 35 ++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
index 8446f1e..ddc3660 100644
--- a/Documentation/rtc.txt
+++ b/Documentation/rtc.txt
@@ -157,6 +157,12 @@ wakealarm:  The time at which the clock will generate a 
system wakeup
 the epoch by default, or if there's a leading +, seconds in the
 future, or if there is a leading +=, seconds ahead of the 
current
 alarm.
+offset: The amount which the rtc clock has been adjusted in 
firmware.
+Visible only if the driver supports clock offset adjustment.
+The unit is parts per billion, i.e. The number of clock ticks
+which are added to or removed from the rtc's base clock per
+billion ticks. A positive value makes a day pass more slowly,
+longer, and a negative value makes a day pass more quickly.
 
 IOCTL INTERFACE
 ---
diff --git a/drivers/rtc/rtc-sysfs.c b/drivers/rtc/rtc-sysfs.c
index 463e286..63b9fb1 100644
--- a/drivers/rtc/rtc-sysfs.c
+++ b/drivers/rtc/rtc-sysfs.c
@@ -218,6 +218,34 @@ wakealarm_store(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RW(wakealarm);
 
+static ssize_t
+offset_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+   ssize_t retval;
+   long offset;
+
+   retval = rtc_read_offset(to_rtc_device(dev), );
+   if (retval == 0)
+   retval = sprintf(buf, "%ld\n", offset);
+
+   return retval;
+}
+
+static ssize_t
+offset_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t n)
+{
+   ssize_t retval;
+   long offset;
+
+   retval = kstrtol(buf, 10, );
+   if (retval == 0)
+   retval = rtc_set_offset(to_rtc_device(dev), offset);
+
+   return (retval < 0) ? retval : n;
+}
+static DEVICE_ATTR_RW(offset);
+
 static struct attribute *rtc_attrs[] = {
_attr_name.attr,
_attr_date.attr,
@@ -226,6 +254,7 @@ static struct attribute *rtc_attrs[] = {
_attr_max_user_freq.attr,
_attr_hctosys.attr,
_attr_wakealarm.attr,
+   _attr_offset.attr,
NULL,
 };
 
@@ -249,9 +278,13 @@ static umode_t rtc_attr_is_visible(struct kobject *kobj,
struct rtc_device *rtc = to_rtc_device(dev);
umode_t mode = attr->mode;
 
-   if (attr == _attr_wakealarm.attr)
+   if (attr == _attr_wakealarm.attr) {
if (!rtc_does_wakealarm(rtc))
mode = 0;
+   } else if (attr == _attr_offset.attr) {
+   if (!rtc->ops->set_offset)
+   mode = 0;
+   }
 
return mode;
 }
-- 
2.5.0

--
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 v4 3/3] rtc-pcf2123: implement read_offset and set_offset

2016-02-05 Thread Joshua Clayton 
pcf2123 has an offset register, which can be used to make minor
adjustments to the clock rate to compensate for temperature or
a crystal that is not exactly right.

Signed-off-by: Joshua Clayton 
---
 drivers/rtc/rtc-pcf2123.c | 57 +++
 1 file changed, 57 insertions(+)

diff --git a/drivers/rtc/rtc-pcf2123.c b/drivers/rtc/rtc-pcf2123.c
index d9a44ad..da27738 100644
--- a/drivers/rtc/rtc-pcf2123.c
+++ b/drivers/rtc/rtc-pcf2123.c
@@ -100,6 +100,7 @@
 /* PCF2123_REG_OFFSET BITS */
 #define OFFSET_SIGN_BITBIT(6)  /* 2's complement sign bit */
 #define OFFSET_COARSE  BIT(7)  /* Coarse mode offset */
+#define OFFSET_STEP(2170)  /* Offset step in parts per billion */
 
 /* READ/WRITE ADDRESS BITS */
 #define PCF2123_WRITE  BIT(4)
@@ -206,6 +207,59 @@ static ssize_t pcf2123_store(struct device *dev, struct 
device_attribute *attr,
return count;
 }
 
+static int pcf2123_read_offset(struct device *dev, long *offset)
+{
+   int ret;
+   s8 reg;
+
+   ret = pcf2123_read(dev, PCF2123_REG_OFFSET, , 1);
+   if (ret < 0)
+   return ret;
+
+   if (reg & OFFSET_COARSE)
+   reg <<= 1; /* multiply by 2 and sign extend */
+   else
+   reg |= (reg & OFFSET_SIGN_BIT) << 1; /* sign extend only */
+
+   *offset = ((long)reg) * OFFSET_STEP;
+
+   return 0;
+}
+
+/*
+ * The offset register is a 7 bit signed value with a coarse bit in bit 7.
+ * The main difference between the two is normal offset adjusts the first
+ * second of n minutes every other hour, with 61, 62 and 63 being shoved
+ * into the 60th minute.
+ * The coarse adjustment does the same, but every hour.
+ * the two overlap, with every even normal offset value corresponding
+ * to a coarse offset. Based on this algorithm, it seems that despite the
+ * name, coarse offset is a better fit for overlapping values.
+ */
+static int pcf2123_set_offset(struct device *dev, long offset)
+{
+   s8 reg;
+
+   if (offset > OFFSET_STEP * 127)
+   reg = 127;
+   else if (offset < OFFSET_STEP * -128)
+   reg = -128;
+   else
+   reg = (s8)((offset + (OFFSET_STEP >> 1)) / OFFSET_STEP);
+
+   /* choose fine offset only for odd values in the normal range */
+   if (reg & 1 && reg <= 63 && reg >= -64) {
+   /* Normal offset. Clear the coarse bit */
+   reg &= ~OFFSET_COARSE;
+   } else {
+   /* Coarse offset. Divide by 2 and set the coarse bit */
+   reg >>= 1;
+   reg |= OFFSET_COARSE;
+   }
+
+   return pcf2123_write_reg(dev, PCF2123_REG_OFFSET, reg);
+}
+
 static int pcf2123_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
u8 rxbuf[7];
@@ -314,6 +368,9 @@ static int pcf2123_reset(struct device *dev)
 static const struct rtc_class_ops pcf2123_rtc_ops = {
.read_time  = pcf2123_rtc_read_time,
.set_time   = pcf2123_rtc_set_time,
+   .read_offset= pcf2123_read_offset,
+   .set_offset = pcf2123_set_offset,
+
 };
 
 static int pcf2123_probe(struct spi_device *spi)
-- 
2.5.0

--
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 v16 2/6] add sysfs document for fpga bridge class

2016-02-05 Thread atull 
From: Alan Tull 

Add documentation for new FPGA bridge class's sysfs interface.

Signed-off-by: Alan Tull 
--
v15: Document added in v15 of patch set
v16: No change to this patch in v16 of patch set
---
 Documentation/ABI/testing/sysfs-class-fpga-bridge |   11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge

diff --git a/Documentation/ABI/testing/sysfs-class-fpga-bridge 
b/Documentation/ABI/testing/sysfs-class-fpga-bridge
new file mode 100644
index 000..312ae2c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-fpga-bridge
@@ -0,0 +1,11 @@
+What:  /sys/class/fpga_bridge//name
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull 
+Description:   Name of low level FPGA bridge driver.
+
+What:  /sys/class/fpga_bridge//state
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull 
+Description:   Show bridge state as "enabled" or "disabled"
-- 
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 v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

2016-02-05 Thread Fu Wei 
On 5 February 2016 at 00:43, Timur Tabi  wrote:
> Mathieu Poirier wrote:
>>>
>>> >+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>>> >+   irq = platform_get_irq(pdev, 0);
>>> >+   if (irq < 0) {
>>> >+   dev_err(dev, "unable to get ws0 interrupt.\n");
>>> >+   return irq;
>>> >+   }
>>> >+#endif
>>> >+
>>
>> Can't the driver revert to single stage mode if platform_get_irq()
>> fails?  That way the value of 'irq' can be tested throughout the
>> _probe() function and the #ifdefs removed.
>
>
> I like that idea.  The same can be done with the devm_request_irq() call.
> It should definitely still display a warning if the command-line option is
> set but no interrupt is available.

Yes, I agree with that too, brilliant idea, this will be in v11 patchset



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
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 3/6] stm class: provision for statically assigned masterIDs

2016-02-05 Thread Alexander Shishkin 
Chunyan Zhang  writes:

> From: Mathieu Poirier 
>
> Some architecture like ARM assign masterIDs statically at the HW design
> phase, making masterID manipulation in the generic STM core irrelevant.
>
> This patch adds a new 'mstatic' flag to struct stm_data that tells the
> core that this specific STM device doesn't need explicit masterID
> management.

So why do we need this patch? If your STM only has master 42 allocated
for software sources, simply set sw_start = 42, sw_end = 42 and you're
good to go, software will have exactly one channel to choose from. See
also the comment from :

 * @sw_start:   first STP master available to software
 * @sw_end: last STP master available to software

particularly the "available to software" part. Any other kinds of
masters the STM class code doesn't care about (yet).

> In the core sw_start/end of masterID are set to '1',
> i.e there is only one masterID to deal with.

This is also a completely arbitrary and unnecessary requirement. Again,
you can set both to 42 and it will still work.

> Also this patch depends on [1], so that the number of masterID
> is '1' too.
>
> Finally the lower and upper bound for masterIDs as presented
> in ($SYSFS)/class/stm/XYZ.stm/masters and
> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
> are set to '-1'.  That way users can't confuse them with
> architecture where masterID management is required (where any
> other value would be valid).

Why is this a good idea? Having the actual master there will allow
software to know what it is and also tell the decoding side what it is
(assuming you have more than one source in the STP stream, it might not
be easy to figure out, unless you know it in advance).

I don't see how one master statically assigned to software sources is
different from two masters or 32 masters. And I don't see any benefit of
hiding the master id from userspace. Am I missing something?

Regards,
--
Alex
--
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 1/6] stm class: Add ioctl get_options interface

2016-02-05 Thread Alexander Shishkin 
Chunyan Zhang  writes:

> There is already an interface of set_options, but no get_options yet.
> Before setting any options, one would may want to see the current
> status of that option by means of get_options interface. This
> interface has been used in CoreSight STM driver.
>
> Signed-off-by: Chunyan Zhang 
> ---
>  drivers/hwtracing/stm/core.c | 11 +++
>  include/linux/stm.h  |  3 +++
>  include/uapi/linux/stm.h |  1 +
>  3 files changed, 15 insertions(+)
>
> diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
> index b6445d9..86bb4e3 100644
> --- a/drivers/hwtracing/stm/core.c
> +++ b/drivers/hwtracing/stm/core.c
> @@ -571,6 +571,17 @@ stm_char_ioctl(struct file *file, unsigned int cmd, 
> unsigned long arg)
>   options);
>  
>   break;
> +
> + case STP_GET_OPTIONS:
> + if (stm_data->get_options)
> + err = stm_data->get_options(stm_data,
> + stmf->output.master,
> + stmf->output.channel,
> + stmf->output.nr_chans,
> + );
> +
> + return copy_to_user((void __user *)arg, , sizeof(u64));

The return value of copy_to_user() is not what you assume it is.

Regards,
--
Alex
--
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 v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

2016-02-05 Thread Thomas Petazzoni 
Hello,

On Fri, 5 Feb 2016 17:51:52 +0800, Fu Wei wrote:

> OK, my thought is
> 
> if panic is enabled :
> |WOR---WS0WOR---WS1
> |--timeout--(panic)--timeout-reset

I'm quite certainly missing something completely obvious here, but how
can you get the WS1 interrupt *after* raising a panic? Aren't all
interrupts disabled and the system fully halted once you get a panic(),
especially when raised from an interrupt handler? If that's the case,
how can the system continue to do things, such as receiving the WS1
interrupt and resetting ?

Again, I'm probably missing something obvious, but I'm interested to
understand the reasoning here.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-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 6/6] coresight-stm: adding driver for CoreSight STM component

2016-02-05 Thread Alexander Shishkin 
Chunyan Zhang  writes:

> +#ifndef CONFIG_64BIT
> +static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
> +{
> + asm volatile("strd %1, %0"
> +  : "+Qo" (*(volatile u64 __force *)addr)
> +  : "r" (val));
> +}

Is it really ok to do this for all !64bit arms, inside a driver, just
like that? I'm not an expert, but I'm pretty sure there's more to it.

Regards,
--
Alex
--
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 v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

2016-02-05 Thread Timur Tabi 

Thomas Petazzoni wrote:

if panic is enabled :
>|WOR---WS0WOR---WS1
>|--timeout--(panic)--timeout-reset



I'm quite certainly missing something completely obvious here, but how
can you get the WS1 interrupt*after*  raising a panic? Aren't all
interrupts disabled and the system fully halted once you get a panic(),
especially when raised from an interrupt handler? If that's the case,
how can the system continue to do things, such as receiving the WS1
interrupt and resetting ?


Typically, WS1 is not an interrupt.  Instead, it's a hard system-level 
reset.


The hardware is capable of generating an interrupt for both WS0 and WS1. 
 However, the ACPI table only contains one interrupt value, and it's 
not clear whether that's supposed to be the WS0 interrupt or the WS1 
interrupts.


So this whole thing does assume a specfic watchdog configuration.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
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 v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

2016-02-05 Thread Thomas Petazzoni 
Hello,

On Fri, 5 Feb 2016 07:08:23 -0600, Timur Tabi wrote:

> > I'm quite certainly missing something completely obvious here, but how
> > can you get the WS1 interrupt*after*  raising a panic? Aren't all
> > interrupts disabled and the system fully halted once you get a panic(),
> > especially when raised from an interrupt handler? If that's the case,
> > how can the system continue to do things, such as receiving the WS1
> > interrupt and resetting ?
> 
> Typically, WS1 is not an interrupt.  Instead, it's a hard system-level 
> reset.

Ah, right, true. I missed that aspect because on my HW, triggering a
system-level reset on WS1 is optional. I can actually get an interrupt
on both WS0 and WS1, and no reset at all.

But a normal configuration indeed involves having the WS1 event
configured in HW to be a system-level reset.

So, OK, it makes sense. Thanks for the clarification!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-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 v10 4/5] Watchdog: introduce ARM SBSA watchdog driver

2016-02-05 Thread Fu Wei 
Hi

On 5 February 2016 at 00:46, Guenter Roeck  wrote:
> On 02/04/2016 08:37 AM, Timur Tabi wrote:
>>
>> Will Deacon wrote:

 +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
 >+{
 >+struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
 >+
 >+/*
 >+* Writing WRR for an explicit watchdog refresh.
 >+* You can write anyting(like 0xc0ffee).
 >+*/
 >+writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
 >+
 >+return 0;
 >+}
>>>
>>> You might get in trouble for that. 0xd09f00d is probably less poisonous.
>>>
>>> http://www.petpoisonhelpline.com/poison/caffeine/
>>
>>
>> Any reason why we can't just keep it simple and write 0?
>
>
> +1

yes, we can, just "0" would be fine, will do.

Thanks :-)

>
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
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 v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

2016-02-05 Thread Guenter Roeck 

On 02/05/2016 01:51 AM, Fu Wei wrote:

Hi Guenter,

On 4 February 2016 at 13:17, Guenter Roeck  wrote:

On 02/03/2016 03:00 PM, Fu Wei wrote:


On 4 February 2016 at 02:45, Timur Tabi  wrote:


Fu Wei wrote:



As you know I have made the pre-timeout support patch, If people like
it, i am happy to go on upstream it separately.

If we want to use pre-timeout here, user only can use get_pretimeout
and disable panic by setting pretimeout to 0
but user can not really set pretimeout, because "pre-timeout  ==
timeout / 2 (always)".
if user want to change pretimeout, he/she has to set_time instead.




Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
entry should be removed and just use panic_enabled.



Agreed.


np, will do




NP, will update this patchset like that ,  thanks :-)



Also, if panic is enabled, the timeout needs to be adjusted accordingly
(to only panic after the entire timeout period has expired, not after
half of it). We can not panic the system after timeout / 2.


OK, my thought is

if panic is enabled :
|WOR---WS0WOR---WS1
|--timeout--(panic)--timeout-reset

if panic is disabled .
|WOR---WS0WOR---WS1
|-timeout-reset

  panic_enabled only can be configured when module is loaded by module parameter

But user should know that max_timeout(panic_enable) =
max_timeout(panic_disable) / 2



That means you'll have to update max_timeout accordingly.



I am not too happy with the parameter name (panic_enabled). How about
"action", to match machzwd ?


yes, makes sense. Maybe we can do something  like this:

/*
  * action refers to action taken when watchdog gets WS0
  * 0 = SKIP
  * 1 = PANIC
  * defaults to SKIP (0)
  */
static int action;
module_param(action, int, 0);
MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
"0 = SKIP(*)  1 = PANIC");


Yes, though I would suggest to use lower case letters.

Thanks,
Guenter

--
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 v4 02/11] drm/hisilicon: Add hisilicon kirin drm master driver

2016-02-05 Thread Xinliang Liu 
Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
Add dumb buffer feature.
Add prime dmabuf feature.

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: Xinwei Kong 
Signed-off-by: Xinliang Liu 
---
 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 | 321 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
 8 files changed, 366 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 ..789ebd1f5922
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -0,0 +1,321 @@
+/*
+ * 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 = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
+
+static void kirin_drm_mode_config_init(struct drm_device

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

2016-02-05 Thread Xinliang Liu 
Add ADE display controller binding doc.
Add DesignWare DSI Host Controller v1.20a binding doc.

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: Xinwei Kong 
Signed-off-by: Xinliang Liu 
---
 .../bindings/display/hisilicon/dw-dsi.txt  | 77 ++
 .../bindings/display/hisilicon/hisi-ade.txt| 69 +++
 2 files changed, 146 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 ..af6d702f3282
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
@@ -0,0 +1,77 @@
+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.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-dsi".
+- reg: physical base address and length of dsi controller's registers.
+- clocks: the clocks needed.
+- clock-names: the name of the clocks.
+- 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. And the reg value for bridge endpoint is "0",
+  other values for panel endpoint.
+  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_dsi";
+   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 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   /* 0 for bridge, other value for panel */
+   dsi_out0: endpoint@0 {
+   reg = <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 ..1eff5a41b98d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
@@ -0,0 +1,69 @@
+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 controller's registers.
+  Three reg ranges are used in ADE driver:
+  ADE reg range, value should be "<0x0 0xf410 0x0 0x7800>";
+  media subsystem reg range, value should be "<0x0 0xf441 0x0 0x1000>";
+  media subsystem NOC QoS reg range, value should be "<0x0 0xf452 0x0
+  0x1000>".
+- reg-names: name of physical base.Valuse should be "ade_base",
"media_base"
+  and "media_noc_base".
+- interrupt: the ldi vblank interrupt number used.
+- clocks: the clocks needed. Three clocks are used in ADE driver:
+  ADE core clock, value should be "<_ctrl

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

2016-02-05 Thread Xinliang Liu 
Add plane funcs and helper funcs for ADE.

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

Signed-off-by: Xinliang Liu 
---
 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 b45149616716..ff70f1c3dd78 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -24,13 +24,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;
void __iomem  *media_base;
@@ -49,11 +59,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_NOT_SUPPORT;
+}
+
 static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
 {
u32 bit_ofst, reg_num;
@@ -86,7 +161,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));
@@ -144,6 +219,10 @@ static void ade_ldi_set_mode(struct ade_crtc *acrtc,
  mode->clock * 1000, ret);
adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
 
+   /* 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 */
@@ -222,6 +301,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);
 
@@ -235,6 +318,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 reg_ctrl, reg_addr, reg_size, reg_stride, reg_space,

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

2016-02-05 Thread Xinliang Liu 
Add DesignWare dsi host driver for hi6220 SoC.

v4: None.
v3: None.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 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 7c9423537b71..2837af01e935 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,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;
@@ -642,6 +643,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);
@@ -653,6 +699,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;
 }
 
-- 
1.9.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 v4 06/11] drm/hisilicon: Add cma fbdev and hotplug

2016-02-05 Thread Xinliang Liu 
Add cma Fbdev, Fbdev is legency and optional, you can enable/disable it by
configuring DRM_FBDEV_EMULATION.
Add hotplug.

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

Signed-off-by: Xinliang Liu 
---
 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 723888feb760..d57b9fa0ce3e 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;
-- 
1.9.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 v4 05/11] drm/hisilicon: Add vblank driver for ADE

2016-02-05 Thread Xinliang Liu 
Add vblank irq handle.

v4: None.
v3:
- Remove hisi_get_crtc_from_index func.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 62 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 14 +-
 2 files changed, 75 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 ff70f1c3dd78..2a12e14ea6ab 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -295,6 +295,59 @@ static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
writel(val, reg);
 }
 
+static int ade_enable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   struct kirin_drm_private *priv = dev->dev_private;
+   struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+   struct ade_hw_ctx *ctx = acrtc->ctx;
+   void __iomem *base = ctx->base;
+
+   if (!ctx->power_on)
+   (void)ade_power_up(ctx);
+
+   ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+   MASK(1), 1);
+
+   return 0;
+}
+
+static void ade_disable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   struct kirin_drm_private *priv = dev->dev_private;
+   struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+   struct ade_hw_ctx *ctx = acrtc->ctx;
+   void __iomem *base = ctx->base;
+
+   if (!ctx->power_on) {
+   DRM_ERROR("power is down! vblank disable fail\n");
+   return;
+   }
+
+   ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+   MASK(1), 0);
+}
+
+static irqreturn_t ade_irq_handler(int irq, void *data)
+{
+   struct ade_crtc *acrtc = data;
+   struct ade_hw_ctx *ctx = acrtc->ctx;
+   struct drm_crtc *crtc = >base;
+   void __iomem *base = ctx->base;
+   u32 status;
+
+   status = readl(base + LDI_MSK_INT);
+   DRM_DEBUG_VBL("LDI IRQ: status=0x%X\n", status);
+
+   /* vblank irq */
+   if (status & BIT(FRAME_END_INT_EN_OFST)) {
+   ade_update_bits(base + LDI_INT_CLR, FRAME_END_INT_EN_OFST,
+   MASK(1), 1);
+   drm_crtc_handle_vblank(crtc);
+   }
+
+   return IRQ_HANDLED;
+}
+
 static void ade_display_enable(struct ade_crtc *acrtc)
 {
struct ade_hw_ctx *ctx = acrtc->ctx;
@@ -973,6 +1026,15 @@ int ade_drm_init(struct drm_device *dev)
if (ret)
return ret;
 
+   /* vblank irq init */
+   ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler,
+  DRIVER_IRQ_SHARED, dev->driver->name, acrtc);
+   if (ret)
+   return ret;
+   dev->driver->get_vblank_counter = drm_vblank_no_hw_counter;
+   dev->driver->enable_vblank = ade_enable_vblank;
+   dev->driver->disable_vblank = ade_disable_vblank;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 055729c1889c..723888feb760 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -32,6 +32,7 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;
 
+   drm_vblank_cleanup(dev);
dc_ops->cleanup(dev);
drm_mode_config_cleanup(dev);
devm_kfree(dev->dev, priv);
@@ -85,11 +86,22 @@ static int kirin_drm_kms_init(struct drm_device *dev)
goto err_dc_cleanup;
}
 
+   /* vblank init */
+   ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
+   if (ret) {
+   DRM_ERROR("failed to initialize vblank.\n");
+   goto err_unbind_all;
+   }
+   /* with irq_enabled = true, we can use the vblank feature. */
+   dev->irq_enabled = true;
+
/* reset all the states of crtc/plane/encoder/connector */
drm_mode_config_reset(dev);
 
return 0;
 
+err_unbind_all:
+   component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
dc_ops->cleanup(dev);
 err_mode_config_cleanup:
@@ -123,7 +135,7 @@ static int kirin_gem_cma_dumb_create(struct drm_file *file,
 
 static struct drm_driver kirin_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
- DRIVER_ATOMIC,
+ DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
.fops   = _drm_fops,
.set_busid  = drm_platform_set_busid,
 
-- 
1.9.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 v4 10/11] MAINTAINERS: Add maintainer for hisilicon DRM driver

2016-02-05 Thread Xinliang Liu 
Add maintainer and reviewer for hisilicon DRM driver.

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 30aca4aa5467..730ebc571edf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3777,6 +3777,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 
-- 
1.9.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 v4 09/11] drm/hisilicon: Add support for external bridge

2016-02-05 Thread Xinliang Liu 
Add support for external HDMI bridge.

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

Signed-off-by: Xinliang Liu 
---
 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 2837af01e935..1342d84d7c68 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,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;
@@ -688,6 +689,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);
@@ -703,6 +723,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;
 }
 
@@ -719,8 +743,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->dsi_cfg_clk = devm_clk_get(>dev, "pclk_dsi");
if (IS_ERR(ctx->dsi_cfg_clk)) {
DRM_ERROR("failed to get dsi plck clock\n");
-- 
1.9.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 v4 11/11] arm64: dts: hisilicon: Add display subsystem DT nodes for hi6220

2016-02-05 Thread Xinliang Liu 
Add ade, dsi and adv7533 DT nodes for hikey board.

Signed-off-by: Xinliang Liu 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 44 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  | 53 ++
 2 files changed, 97 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 818525197508..5c3557c8e59b 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -39,3 +39,47 @@
  {
label = "LS-UART1";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "ok";
+
+   ports {
+/* 1 for output port */
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   /* 0 for bridge, other value for panel */
+   dsi_out0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
+
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "ok";
+
+   adv7533: adv7533@39 {
+   compatible = "adi,adv7533";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <1 2>;
+   pd-gpio = < 4 0>;
+   adi,dsi-lanes = <4>;
+
+   port {
+   adv7533_in: endpoint {
+   remote-endpoint = <_out0>;
+   };
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index ad1f1ebcb05c..e50e81cdd242 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -209,5 +209,58 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+   ade: ade@f410 {
+   compatible = "hisilicon,hi6220-ade";
+   reg = <0x0 0xf410 0x0 0x7800>,
+ <0x0 0xf441 0x0 0x1000>,
+ <0x0 0xf452 0x0 0x1000>;
+   reg-names = "ade_base",
+   "media_base",
+   "media_noc_base";
+
+   interrupts = <0 115 4>; /* ldi interrupt */
+
+   clocks = <_ctrl HI6220_ADE_CORE>,
+<_ctrl HI6220_CODEC_JPEG>,
+<_ctrl HI6220_ADE_PIX_SRC>;
+   /*clock name*/
+   clock-names  = "clk_ade_core",
+  "clk_codec_jpeg",
+  "clk_ade_pix";
+
+   assigned-clocks = <_ctrl HI6220_ADE_CORE>,
+   <_ctrl HI6220_CODEC_JPEG>;
+   assigned-clock-rates = <36000>, <28800>;
+   dma-coherent;
+   status = "disabled";
+
+   port {
+   ade_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
+   dsi: dsi@f4107800 {
+   compatible = "hisilicon,hi6220-dsi";
+   reg = <0x0 0xf4107800 0x0 0x100>;
+   clocks = <_ctrl  HI6220_DSI_PCLK>;
+   clock-names = "pclk_dsi";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* 0 for input port */
+   port@0 {
+   reg = <0>;
+   dsi_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
};
 };
-- 
1.9.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 v4 00/11] Add DRM Driver for HiSilicon Kirin hi6220 SoC

2016-02-05 Thread 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 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 relavant 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  |   77 ++
 .../bindings/display/hisilicon/hisi-ade.txt|   69 ++
 MAINTAINERS|   10 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   44 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |   53 +
 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   |  845 
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h   |   83 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h|  280 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c| 1053 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  382 +++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h|   31 +
 17 files changed, 2955 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 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

-- 
1.9.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

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

2016-02-05 Thread Guenter Roeck 

On 02/05/2016 10:21 AM, Fu Wei wrote:

On 5 February 2016 at 22:42, Guenter Roeck  wrote:

On 02/05/2016 01:51 AM, Fu Wei wrote:


Hi Guenter,

On 4 February 2016 at 13:17, Guenter Roeck  wrote:


On 02/03/2016 03:00 PM, Fu Wei wrote:



On 4 February 2016 at 02:45, Timur Tabi  wrote:



Fu Wei wrote:




As you know I have made the pre-timeout support patch, If people like
it, i am happy to go on upstream it separately.

If we want to use pre-timeout here, user only can use get_pretimeout
and disable panic by setting pretimeout to 0
but user can not really set pretimeout, because "pre-timeout  ==
timeout / 2 (always)".
if user want to change pretimeout, he/she has to set_time instead.





Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
entry should be removed and just use panic_enabled.




Agreed.



np, will do




NP, will update this patchset like that ,  thanks :-)



Also, if panic is enabled, the timeout needs to be adjusted accordingly
(to only panic after the entire timeout period has expired, not after
half of it). We can not panic the system after timeout / 2.



OK, my thought is

if panic is enabled :
|WOR---WS0WOR---WS1
|--timeout--(panic)--timeout-reset

if panic is disabled .
|WOR---WS0WOR---WS1
|-timeout-reset

   panic_enabled only can be configured when module is loaded by module
parameter

But user should know that max_timeout(panic_enable) =
max_timeout(panic_disable) / 2



That means you'll have to update max_timeout accordingly.


panic_enabled only can be configured when module is loaded, so we
don't need to update it.

max_timeout will only be set up in the init stage.

Does it make sense ? :-)


Not sure I understand your problem or question.

max_timeout will have to reflect the correct maximum timeout, under
all circumstances. It will have to be set to the correct value before
the watchdog driver is registered.

Guenter

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