Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v5 1/2] Add OV5647 device tree documentation
From: Ramiro Oliveira @ 2016-12-12 12:15 UTC (permalink / raw)
  To: Sakari Ailus, Ramiro Oliveira
  Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-media-u79uwXL29TY76Z2rM5mHXA,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
	linux-0h96xk9xTtrk1uMJSBkQmQ, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
	dheitmueller-eb9eJ82Ua7k9XoPSrs7Ehg,
	slongerbeam-Re5JQEeQqe8AvxtiuMwx3w, lars-Qo5EllUWu/uELgA04lAiVw,
	robert.jarzmik-GANU6spQydw, pavel-+ZI9xUNit7I,
	pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
	sakari.ailus-VuQAYsv1563Yd54FQh9/CA, mark.rutland-5wv7dgnIgG8,
	CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <20161212114900.GS16630-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>

Hi Sakari

On 12/12/2016 11:49 AM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> On Mon, Dec 12, 2016 at 11:39:31AM +0000, Ramiro Oliveira wrote:
>> Hi Sakari,
>>
>> Thank you for the feedback.
>>
>> On 12/7/2016 10:33 PM, Sakari Ailus wrote:
>>> Hi Ramiro,
>>>
>>> Thank you for the patch.
>>>
>>> On Mon, Dec 05, 2016 at 05:36:33PM +0000, Ramiro Oliveira wrote:
>>>> Add device tree documentation.
>>>>
>>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>> ---
>>>>  .../devicetree/bindings/media/i2c/ov5647.txt          | 19 +++++++++++++++++++
>>>>  1 file changed, 19 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>> new file mode 100644
>>>> index 0000000..4c91b3b
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>> @@ -0,0 +1,19 @@
>>>> +Omnivision OV5647 raw image sensor
>>>> +---------------------------------
>>>> +
>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>>> +and CCI (I2C compatible) control bus.
>>>> +
>>>> +Required properties:
>>>> +
>>>> +- compatible	: "ovti,ov5647";
>>>> +- reg		: I2C slave address of the sensor;
>>>> +
>>>> +The common video interfaces bindings (see video-interfaces.txt) should be
>>>> +used to specify link to the image data receiver. The OV5647 device
>>>> +node should contain one 'port' child node with an 'endpoint' subnode.
>>>> +
>>>> +Following properties are valid for the endpoint node:
>>>> +
>>>> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
>>>> +  video-interfaces.txt.  The sensor supports only two data lanes.
>>>
>>> Doesn't this sensor require a external clock, a reset GPIO and / or a
>>> regulator or a few? Do you need data-lanes, unless you can change the order
>>> or the number?
>>
>> In the setup I'm using, I'm not aware of any reset GPIO or regulator. I do use a
>> external clock but it's fixed and not controlled by SW. Should I add a property
>> for this?
> 
> The sensor datasheet defines a power-up and power-down sequence for the
> device. If you don't implement these sequences in the driver on a DT based
> system, nothing suggests that they're implemented correctly. Could it be
> that the boot loader simply enables the regulators or another device
> requires them to be enabled?
> 
> I presume at least the reset GPIO should be controlled explicitly in order
> to ensure correct function. Although hardware can be surprising: I have one
> production system that has no reset GPIO for the sensor albeit the sensor
> datasheet says that's part of the power up sequence.
> 

Sorry for the misunderstanding. I wanted to say that, there is no SW controlled
reset. In the board we're using to connect the sensor to our D-PHY we have a
GPIO controller that when it receives power, it removes the sensor from reset,
so I have no control over that.

Regarding the clock, should I create a new property?

And also, regarding the data-lanes, AFAIK it isn't possible to change the order
of the data and clock lanes so should I remove that property?

>>
>>>
>>> An example DT snippet wouldn't hurt.
>>
>> Sure, I can add a example snippet.
>>
>>>
>>
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v6 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings
From: Peter Rosin @ 2016-12-12 12:18 UTC (permalink / raw)
  To: Jonathan Cameron, Rob Herring
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Mark Rutland,
	Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
	Jonathan Corbet, Arnd Bergmann, Greg Kroah-Hartman,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d2726499-4034-8d5d-4cff-61da86af5add-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

On 2016-12-10 19:21, Jonathan Cameron wrote:
> On 06/12/16 09:18, Peter Rosin wrote:
>> On 2016-12-06 00:26, Rob Herring wrote:
>>> On Wed, Nov 30, 2016 at 09:16:58AM +0100, Peter Rosin wrote:
>>>> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>>>> ---
>>>>  .../bindings/iio/multiplexer/iio-mux.txt           | 40 ++++++++++++++++++++++
>>>>  MAINTAINERS                                        |  6 ++++
>>>>  2 files changed, 46 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
>>>
>>> I'm still not convinced about this binding, but don't really have more 
>>> comments ATM. Sending 6 versions in 2 weeks or so doesn't really help 
>>> either.
>>
>> Sorry about the noise, I'll try to be more careful going forward. On
>> the flip side, I haven't touched the code since v6.
>>
>> I don't see how bindings that are as flexible as the current (and
>> original) phandle link between the mux consumer and the mux controller
>> would look, and at the same time be simpler to understand. You need
>> to be able to refer to a mux controller from several mux consumers, and
>> you need to support several mux controllers in one node (the ADG792A
>> case). And, AFAICT, the complex case wasn't really the problem, it was
>> that it is overly complex to describe the simple case of one mux
>> consumer and one mux controller. But in your comment for v2 [1] you
>> said that I was working around limitations with shared GPIO pins. But
>> solving that in the GPIO subsystem would not solve all that the
>> phandle approach is solving, since you would not have support for
>> ADG792A (or other non-GPIO controlled muxes). So, I think listing
>> the gpio pins inside the mux consumer node is a non-starter, the mux
>> controller has to live in its own node with its own compatible.
>>
>> Would you be happier if I managed to marry the phandle approach with
>> the option of having the mux controller as a child node of the mux
>> consumer for the simple case?
>>
>> I added an example at the end of this message (the same as the first
>> example in v4 [2], at least in principle) for easy comparison between
>> the phandle and the controller-in-child-node approaches. I can't say
>> that I personally find the difference all that significant, and do not
>> think it is worth it. As I see it, the "simple option" would just muddy
>> the waters...
>>
>> [1] http://marc.info/?l=linux-kernel&m=147948334204795&w=2
>> [2] http://marc.info/?l=linux-kernel&m=148001364904240&w=2
>>
>>>> diff --git a/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt b/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
>>>> new file mode 100644
>>>> index 000000000000..8080cf790d82
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
>>>> @@ -0,0 +1,40 @@
>>>> +IIO multiplexer bindings
>>>> +
>>>> +If a multiplexer is used to select which hardware signal is fed to
>>>> +e.g. an ADC channel, these bindings describe that situation.
>>>> +
>>>> +Required properties:
>>>> +- compatible : "iio-mux"
>>>
>>> This is a Linuxism. perhaps "adc-mux".
>>
>> No, that's not general enough, it could just as well be used to mux a
>> temperature sensor. Or whatever. Hmmm, given that "iio-mux" is bad, perhaps
>> "io-channel-mux" is better? That matches the io-channels property used to
>> refer to the parent channel.
> analog-mux maybe? Makes more sense out of context (though with io-channels defined on
> the next line you have plenty of context here ;)

Not that I care all that much about the name, but that doesn't really
fit if you take e.g. an IIO_INDEX channel. That sounds entirely non-analog
to me, but what do I know? Maybe that example doesn't make sense for some
reason, but I can't help but think that there will be some non-analog
channel in the future, if there isn't one already.

So, my preference is io-channel-mux, as that matches the previous dt
naming for what is muxed. But that's just my opinion, if I'm told that
it should be something else, then that's ok.

I'm more worried about other aspects, such as how to get reviewers and who
is going to take the core mux patches and what tree they are going to be
merged into etc. That is, if this series is going anywhere at all or if
someone is going to put up a road-block for some reason...

Cheers,
peda

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

^ permalink raw reply

* Re: [PATCH v5 1/2] Add OV5647 device tree documentation
From: Sakari Ailus @ 2016-12-12 12:19 UTC (permalink / raw)
  To: Ramiro Oliveira
  Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-media-u79uwXL29TY76Z2rM5mHXA,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
	linux-0h96xk9xTtrk1uMJSBkQmQ, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
	dheitmueller-eb9eJ82Ua7k9XoPSrs7Ehg,
	slongerbeam-Re5JQEeQqe8AvxtiuMwx3w, lars-Qo5EllUWu/uELgA04lAiVw,
	robert.jarzmik-GANU6spQydw, pavel-+ZI9xUNit7I,
	pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
	sakari.ailus-VuQAYsv1563Yd54FQh9/CA, mark.rutland-5wv7dgnIgG8,
	CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <0f72309f-ec5e-4252-f6d7-7a7f7a9dc4c5-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>

Hi Ramiro,

On Mon, Dec 12, 2016 at 12:15:04PM +0000, Ramiro Oliveira wrote:
> Hi Sakari
> 
> On 12/12/2016 11:49 AM, Sakari Ailus wrote:
> > Hi Ramiro,
> > 
> > On Mon, Dec 12, 2016 at 11:39:31AM +0000, Ramiro Oliveira wrote:
> >> Hi Sakari,
> >>
> >> Thank you for the feedback.
> >>
> >> On 12/7/2016 10:33 PM, Sakari Ailus wrote:
> >>> Hi Ramiro,
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Mon, Dec 05, 2016 at 05:36:33PM +0000, Ramiro Oliveira wrote:
> >>>> Add device tree documentation.
> >>>>
> >>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> >>>> ---
> >>>>  .../devicetree/bindings/media/i2c/ov5647.txt          | 19 +++++++++++++++++++
> >>>>  1 file changed, 19 insertions(+)
> >>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>> new file mode 100644
> >>>> index 0000000..4c91b3b
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>> @@ -0,0 +1,19 @@
> >>>> +Omnivision OV5647 raw image sensor
> >>>> +---------------------------------
> >>>> +
> >>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> >>>> +and CCI (I2C compatible) control bus.
> >>>> +
> >>>> +Required properties:
> >>>> +
> >>>> +- compatible	: "ovti,ov5647";
> >>>> +- reg		: I2C slave address of the sensor;
> >>>> +
> >>>> +The common video interfaces bindings (see video-interfaces.txt) should be
> >>>> +used to specify link to the image data receiver. The OV5647 device
> >>>> +node should contain one 'port' child node with an 'endpoint' subnode.
> >>>> +
> >>>> +Following properties are valid for the endpoint node:
> >>>> +
> >>>> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
> >>>> +  video-interfaces.txt.  The sensor supports only two data lanes.
> >>>
> >>> Doesn't this sensor require a external clock, a reset GPIO and / or a
> >>> regulator or a few? Do you need data-lanes, unless you can change the order
> >>> or the number?
> >>
> >> In the setup I'm using, I'm not aware of any reset GPIO or regulator. I do use a
> >> external clock but it's fixed and not controlled by SW. Should I add a property
> >> for this?
> > 
> > The sensor datasheet defines a power-up and power-down sequence for the
> > device. If you don't implement these sequences in the driver on a DT based
> > system, nothing suggests that they're implemented correctly. Could it be
> > that the boot loader simply enables the regulators or another device
> > requires them to be enabled?
> > 
> > I presume at least the reset GPIO should be controlled explicitly in order
> > to ensure correct function. Although hardware can be surprising: I have one
> > production system that has no reset GPIO for the sensor albeit the sensor
> > datasheet says that's part of the power up sequence.
> > 
> 
> Sorry for the misunderstanding. I wanted to say that, there is no SW controlled
> reset. In the board we're using to connect the sensor to our D-PHY we have a
> GPIO controller that when it receives power, it removes the sensor from reset,
> so I have no control over that.

Do you mean to say that there's a GPIO controller but there's not (yet?) a
driver for that or that the reset line is actually hard-wired to something
else?

> 
> Regarding the clock, should I create a new property?

Yes. The sensor does require a clock.

> 
> And also, regarding the data-lanes, AFAIK it isn't possible to change the order
> of the data and clock lanes so should I remove that property?

Sounds good to me.

> 
> >>
> >>>
> >>> An example DT snippet wouldn't hurt.
> >>
> >> Sure, I can add a example snippet.
> >>
> >>>
> >>
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org	XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v7 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings
From: Lorenzo Pieralisi @ 2016-12-12 12:40 UTC (permalink / raw)
  To: Juri Lelli
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
	vincent.guittot-QSEj5FYQhm4dnm+yROfE0A,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	linux-lFZ/pmaqli7XmaaqVzeoHQ, sudeep.holla-5wv7dgnIgG8,
	catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
	morten.rasmussen-5wv7dgnIgG8, dietmar.eggemann-5wv7dgnIgG8,
	broonie-DgEjT+Ai2ygdnm+yROfE0A, Pawel Moll, Ian Campbell,
	Kumar Gala, Maxime Ripard, Olof Johansson, Gregory CLEMENT,
	Paul Walmsley, Linus Walleij, Chen-Yu Tsai, Thomas Petazzoni
In-Reply-To: <1473085372-2840-2-git-send-email-juri.lelli-5wv7dgnIgG8@public.gmane.org>

On Mon, Sep 05, 2016 at 03:22:45PM +0100, Juri Lelli wrote:

[...]

> +===========================================
> +5 - References
> +===========================================
> +
> +[1] ARM Linux Kernel documentation - CPUs bindings
> +    Documentation/devicetree/bindings/arm/cpus.txt
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index e6782d50cbcd..c1dcf4cade2e 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -241,6 +241,14 @@ nodes to be present and contain the properties described below.
>  			# List of phandles to idle state nodes supported
>  			  by this cpu [3].
>  
> +	- capacity-dmips-mhz
> +		Usage: Optional
> +		Value type: <u32>
> +		Definition:
> +			# u32 value representing CPU capacity [3] in
> +			  DMIPS/MHz, relative to highest capacity-dmips-mhz
> +			  in the system.
> +
>  	- rockchip,pmu
>  		Usage: optional for systems that have an "enable-method"
>  		       property value of "rockchip,rk3066-smp"
> @@ -464,3 +472,5 @@ cpus {
>  [2] arm/msm/qcom,kpss-acc.txt
>  [3] ARM Linux kernel documentation - idle states bindings
>      Documentation/devicetree/bindings/arm/idle-states.txt
> +[3] ARM Linux kernel documentation - cpu capacity bindings
> +    Documentation/devicetree/bindings/arm/cpu-capacity.txt

Trivia: bumped into this while reviewing something else, too many
threes, you will have to fix the added reference up.

Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: usb:xhci: support disable usb2 LPM Remote Wakeup
From: Mathias Nyman @ 2016-12-12 13:00 UTC (permalink / raw)
  To: Thang Q. Nguyen, Rob Herring
  Cc: Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Mathias Nyman,
	Greg Kroah-Hartman, devicetree, linux-kernel, linux-usb, Phong Vo,
	Loc Ho, Vu Nguyen, patches
In-Reply-To: <CAKrQpStd4+ZZjdYyq93zq-wnqQCiQmSi5jJrYbuiZX5kVH74YA@mail.gmail.com>

On 12.12.2016 06:00, Thang Q. Nguyen wrote:
> On Sat, Dec 10, 2016 at 4:36 AM, Rob Herring <robh@kernel.org> wrote:
>> On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote:
>>> From: Thang Nguyen <tqnguyen@apm.com>
>>>
>>> As per USB 2.0 link power management addendum ECN, table 1-2, page 4,
>>> device or host initiated via resume signaling; device-initiated resumes
>>> can be optionally enabled/disabled by software. This patch adds support
>>> to control enabling the USB2 RWE feature via DT/ACPI attribute.
>>>
>>> Signed-off-by: Vu Nguyen <vnguyen@apm.com>
>>> Signed-off-by: Thang Nguyen <tqnguyen@apm.com>
>>> ---
>>>   Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>>>   drivers/usb/host/xhci-plat.c                       | 3 +++
>>>   drivers/usb/host/xhci.c                            | 5 ++++-
>>>   drivers/usb/host/xhci.h                            | 1 +
>>>   4 files changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> index 966885c..9b4cd14 100644
>>> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
>>> @@ -25,6 +25,7 @@ Required properties:
>>>
>>>   Optional properties:
>>>     - clocks: reference to a clock
>>> +  - usb2-rwe-disable: disable USB2 LPM Remote Wakeup capable
>>
>> Remote wakeup has been around since USB 1.0 days. Does this need to be
>> USB2 or XHCI specific?
> This is XHCI specific. Per XHCI specification 1.1, remote wakeup is
> optional for XHCI 1.0 and required for XHCI 1.1. This patch provides
> ability for software to disable RWE for USB2 in XHCI1.0 controller.

I think I understand what's going on.

USB:
   
The good old USB2 suspend is called L2. Device enters it after 3ms if there is no link activity.
If a device can remote wakeup (RWE) it's stated in the descriptor. RWE can be turned on
of off using standard SET/CLEAR Fature requests

The LPM L1 USB2 state again is entered with a LPM extended transaction to avoid the
3ms wait before powersaving. L1 state is exit can be done with a simialr RWE as L2 resume.
The RWE from L1 can turned on/off using a bit in the LPM extended transaction.

XHCI:

Specs say that if the device supports RWE we should enable it for LPM L1 exit as well.
This is done by setting the RWE (LPM L1) bit in PORTPMSC register. This bit only affect LPM L1 remote
wake. see 4.23.5.1.1.1

The issue might be that xhci driver never check if the device actually supports RWE, we always
set the PORTPMSC RWE  (for LPM L1) bit.

How about checking something like udev->do_remote_wakeup and setting and setting the bit
based on that.

The function that you are changing,  xhci_set_usb2_hardware_lpm() should only be used if
host has Hardware LPM Cabaility bit (HLC) set for that USB2 port in the
USB 2.0 xHCI Supported Protocol Capability.
Host that don't supprt LPM won't have that set. See xhci 7.2.2.1.3.2
  
-Mathias

^ permalink raw reply

* [PATCH v6 0/5] ARM: dts: da850: tilcdc related DT changes
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
  To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
	Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
	Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King
  Cc: LKML, arm-soc, linux-drm, linux-devicetree, Bartosz Golaszewski

This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.

v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting

v2 -> v3:
- make the commit message in patch [2/2] more detailed
- move the max-pixelclock property to da850.dtsi as the limit
  affects all da850-based boards

v3 -> v4:
- remove the input port from the display node
- move the display ports node to da850-lcdk.dts
- rename the vga_bridge node to vga-bridge
- move the LCDC pins to the LCDC node (from the vga bridge node)

v4 -> v5:
- rename the display label to lcdc
- instead of using the 'dumb-vga-dac' compatible, add bindings for
  ti,ths8135 and use it as the vga-bridge node compatible

v5 -> v6:
- drop the endpoint numbers for nodes with single endpoints
- split patch 2/4 from v5 into two separate patches: one adding DT
  bindings and one adding actual support for ths8135

Bartosz Golaszewski (5):
  ARM: dts: da850: rename the display node label
  drm: bridge: add DT bindings for TI ths8135
  drm: bridge: add support for TI ths8135
  ARM: dts: da850-lcdk: add the vga-bridge node
  ARM: dts: da850: specify the maximum pixel clock rate for tilcdc

 .../bindings/display/bridge/ti,ths8135.txt         | 52 +++++++++++++++++
 arch/arm/boot/dts/da850-lcdk.dts                   | 67 ++++++++++++++++++++++
 arch/arm/boot/dts/da850.dtsi                       |  3 +-
 drivers/gpu/drm/bridge/dumb-vga-dac.c              |  1 +
 4 files changed, 122 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt

-- 
2.9.3

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

^ permalink raw reply

* [PATCH v6 1/5] ARM: dts: da850: rename the display node label
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
  To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
	Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
	Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King
  Cc: linux-devicetree, linux-drm, LKML, arm-soc, Bartosz Golaszewski
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>

The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
The label is also 'display', but change it to 'lcdc' to make it clear
what the underlying hardware is.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/boot/dts/da850.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index ffc6e1a..3f51e59 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -448,7 +448,7 @@
 			dma-names = "tx", "rx";
 		};
 
-		display: display@213000 {
+		lcdc: display@213000 {
 			compatible = "ti,da850-tilcdc";
 			reg = <0x213000 0x1000>;
 			interrupts = <52>;
-- 
2.9.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* [PATCH v6 2/5] drm: bridge: add DT bindings for TI ths8135
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
  To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
	Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
	Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King
  Cc: LKML, arm-soc, linux-drm, linux-devicetree, Bartosz Golaszewski
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

THS8135 is a configurable video DAC. Add DT bindings for this chip.

Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
---
 .../bindings/display/bridge/ti,ths8135.txt         | 52 ++++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
new file mode 100644
index 0000000..87aff90
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
@@ -0,0 +1,52 @@
+THS8135 Video DAC
+-----------------
+
+This is the binding for Texas Instruments THS8135 Video DAC bridge.
+
+Required properties:
+
+- compatible: Must be "ti,ths8135"
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+Example
+-------
+
+vga-bridge {
+	compatible = "ti,ths8135";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+
+			vga_bridge_in: endpoint {
+				reg = <0>;
+				remote-endpoint = <&lcdc_out_vga>;
+			};
+		};
+
+		port@1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+
+			vga_bridge_out: endpoint {
+				reg = <0>;
+				remote-endpoint = <&vga_con_in>;
+			};
+		};
+	};
+};
-- 
2.9.3

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

^ permalink raw reply related

* [PATCH v6 3/5] drm: bridge: add support for TI ths8135
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
  To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
	Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
	Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King
  Cc: linux-devicetree, linux-drm, LKML, arm-soc, Bartosz Golaszewski
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>

THS8135 is a configurable video DAC, but no configuration is actually
necessary to make it work.

For now use the dumb-vga-dac driver to support it.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232..498fa75 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
 
 static const struct of_device_id dumb_vga_match[] = {
 	{ .compatible = "dumb-vga-dac" },
+	{ .compatible = "ti,ths8135" },
 	{},
 };
 MODULE_DEVICE_TABLE(of, dumb_vga_match);
-- 
2.9.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* [PATCH v6 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
  To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
	Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
	Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King
  Cc: linux-devicetree, linux-drm, LKML, arm-soc, Bartosz Golaszewski
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>

Add the vga-bridge node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 arch/arm/boot/dts/da850-lcdk.dts | 67 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..e003111 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -51,6 +51,51 @@
 			system-clock-frequency = <24576000>;
 		};
 	};
+
+	vga-bridge {
+		compatible = "ti,ths8135";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0>;
+
+				vga_bridge_in: endpoint {
+					reg = <0>;
+					remote-endpoint = <&lcdc_out_vga>;
+				};
+			};
+
+			port@1 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <1>;
+
+				vga_bridge_out: endpoint {
+					reg = <0>;
+					remote-endpoint = <&vga_con_in>;
+				};
+			};
+		};
+	};
+
+	vga {
+		compatible = "vga-connector";
+
+		ddc-i2c-bus = <&i2c0>;
+
+		port {
+			vga_con_in: endpoint {
+				remote-endpoint = <&vga_bridge_out>;
+			};
+		};
+	};
 };
 
 &pmx_core {
@@ -236,3 +281,25 @@
 &memctrl {
 	status = "okay";
 };
+
+&lcdc {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&lcd_pins>;
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		lcdc_out: port@1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+
+			lcdc_out_vga: endpoint {
+				reg = <0>;
+				remote-endpoint = <&vga_bridge_in>;
+			};
+		};
+	};
+};
-- 
2.9.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* [PATCH v6 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
From: Bartosz Golaszewski @ 2016-12-12 13:05 UTC (permalink / raw)
  To: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
	Michael Turquette, Sekhar Nori, Rob Herring, Frank Rowand,
	Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King
  Cc: linux-devicetree, linux-drm, LKML, arm-soc, Bartosz Golaszewski
In-Reply-To: <1481547942-24775-1-git-send-email-bgolaszewski@baylibre.com>

At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
is 37.5 MHz[1]. We must filter out any mode for which the calculated
pixel clock rate would exceed this value.

Specify the max-pixelclock property for the display node for
da850-lcdk.

[1] http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/boot/dts/da850.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 3f51e59..ba5bf80 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -452,6 +452,7 @@
 			compatible = "ti,da850-tilcdc";
 			reg = <0x213000 0x1000>;
 			interrupts = <52>;
+			max-pixelclock = <37500>;
 			status = "disabled";
 		};
 	};
-- 
2.9.3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related

* Re: [PATCH v5 1/2] Add OV5647 device tree documentation
From: Ramiro Oliveira @ 2016-12-12 13:07 UTC (permalink / raw)
  To: Sakari Ailus, Ramiro Oliveira
  Cc: mchehab, linux-kernel, linux-media, robh+dt, devicetree, davem,
	gregkh, geert+renesas, akpm, linux, hverkuil, dheitmueller,
	slongerbeam, lars, robert.jarzmik, pavel, pali.rohar,
	sakari.ailus, mark.rutland, CARLOS.PALMINHA
In-Reply-To: <20161212121947.GU16630@valkosipuli.retiisi.org.uk>

Hi Sakari

On 12/12/2016 12:19 PM, Sakari Ailus wrote:
> Hi Ramiro,
> 
> On Mon, Dec 12, 2016 at 12:15:04PM +0000, Ramiro Oliveira wrote:
>> Hi Sakari
>>
>> On 12/12/2016 11:49 AM, Sakari Ailus wrote:
>>> Hi Ramiro,
>>>
>>> On Mon, Dec 12, 2016 at 11:39:31AM +0000, Ramiro Oliveira wrote:
>>>> Hi Sakari,
>>>>
>>>> Thank you for the feedback.
>>>>
>>>> On 12/7/2016 10:33 PM, Sakari Ailus wrote:
>>>>> Hi Ramiro,
>>>>>
>>>>> Thank you for the patch.
>>>>>
>>>>> On Mon, Dec 05, 2016 at 05:36:33PM +0000, Ramiro Oliveira wrote:
>>>>>> Add device tree documentation.
>>>>>>
>>>>>> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
>>>>>> ---
>>>>>>  .../devicetree/bindings/media/i2c/ov5647.txt          | 19 +++++++++++++++++++
>>>>>>  1 file changed, 19 insertions(+)
>>>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..4c91b3b
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
>>>>>> @@ -0,0 +1,19 @@
>>>>>> +Omnivision OV5647 raw image sensor
>>>>>> +---------------------------------
>>>>>> +
>>>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
>>>>>> +and CCI (I2C compatible) control bus.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +
>>>>>> +- compatible	: "ovti,ov5647";
>>>>>> +- reg		: I2C slave address of the sensor;
>>>>>> +
>>>>>> +The common video interfaces bindings (see video-interfaces.txt) should be
>>>>>> +used to specify link to the image data receiver. The OV5647 device
>>>>>> +node should contain one 'port' child node with an 'endpoint' subnode.
>>>>>> +
>>>>>> +Following properties are valid for the endpoint node:
>>>>>> +
>>>>>> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
>>>>>> +  video-interfaces.txt.  The sensor supports only two data lanes.
>>>>>
>>>>> Doesn't this sensor require a external clock, a reset GPIO and / or a
>>>>> regulator or a few? Do you need data-lanes, unless you can change the order
>>>>> or the number?
>>>>
>>>> In the setup I'm using, I'm not aware of any reset GPIO or regulator. I do use a
>>>> external clock but it's fixed and not controlled by SW. Should I add a property
>>>> for this?
>>>
>>> The sensor datasheet defines a power-up and power-down sequence for the
>>> device. If you don't implement these sequences in the driver on a DT based
>>> system, nothing suggests that they're implemented correctly. Could it be
>>> that the boot loader simply enables the regulators or another device
>>> requires them to be enabled?
>>>
>>> I presume at least the reset GPIO should be controlled explicitly in order
>>> to ensure correct function. Although hardware can be surprising: I have one
>>> production system that has no reset GPIO for the sensor albeit the sensor
>>> datasheet says that's part of the power up sequence.
>>>
>>
>> Sorry for the misunderstanding. I wanted to say that, there is no SW controlled
>> reset. In the board we're using to connect the sensor to our D-PHY we have a
>> GPIO controller that when it receives power, it removes the sensor from reset,
>> so I have no control over that.
> 
> Do you mean to say that there's a GPIO controller but there's not (yet?) a
> driver for that or that the reset line is actually hard-wired to something
> else?
> 

The reset line is hardwired to a GPIO controller that when powered-on removes
the sensor from reset. However I have no control over the GPIO controller.

>>
>> Regarding the clock, should I create a new property?
> 
> Yes. The sensor does require a clock.
> 
>>
>> And also, regarding the data-lanes, AFAIK it isn't possible to change the order
>> of the data and clock lanes so should I remove that property?
> 
> Sounds good to me.
> 
>>
>>>>
>>>>>
>>>>> An example DT snippet wouldn't hurt.
>>>>
>>>> Sure, I can add a example snippet.
>>>>
>>>>>
>>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* Re: [PATCH v7 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings
From: Juri Lelli @ 2016-12-12 13:33 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-pm-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
	vincent.guittot-QSEj5FYQhm4dnm+yROfE0A,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	linux-lFZ/pmaqli7XmaaqVzeoHQ, sudeep.holla-5wv7dgnIgG8,
	catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
	morten.rasmussen-5wv7dgnIgG8, dietmar.eggemann-5wv7dgnIgG8,
	broonie-DgEjT+Ai2ygdnm+yROfE0A, Pawel Moll, Ian Campbell,
	Kumar Gala, Maxime Ripard, Olof Johansson, Gregory CLEMENT,
	Paul Walmsley, Linus Walleij, Chen-Yu Tsai, Thomas Petazzoni
In-Reply-To: <20161212124005.GA19177@red-moon>

On 12/12/16 12:40, Lorenzo Pieralisi wrote:
> On Mon, Sep 05, 2016 at 03:22:45PM +0100, Juri Lelli wrote:
> 
> [...]
> 
> > +===========================================
> > +5 - References
> > +===========================================
> > +
> > +[1] ARM Linux Kernel documentation - CPUs bindings
> > +    Documentation/devicetree/bindings/arm/cpus.txt
> > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> > index e6782d50cbcd..c1dcf4cade2e 100644
> > --- a/Documentation/devicetree/bindings/arm/cpus.txt
> > +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> > @@ -241,6 +241,14 @@ nodes to be present and contain the properties described below.
> >  			# List of phandles to idle state nodes supported
> >  			  by this cpu [3].
> >  
> > +	- capacity-dmips-mhz
> > +		Usage: Optional
> > +		Value type: <u32>
> > +		Definition:
> > +			# u32 value representing CPU capacity [3] in
> > +			  DMIPS/MHz, relative to highest capacity-dmips-mhz
> > +			  in the system.
> > +
> >  	- rockchip,pmu
> >  		Usage: optional for systems that have an "enable-method"
> >  		       property value of "rockchip,rk3066-smp"
> > @@ -464,3 +472,5 @@ cpus {
> >  [2] arm/msm/qcom,kpss-acc.txt
> >  [3] ARM Linux kernel documentation - idle states bindings
> >      Documentation/devicetree/bindings/arm/idle-states.txt
> > +[3] ARM Linux kernel documentation - cpu capacity bindings
> > +    Documentation/devicetree/bindings/arm/cpu-capacity.txt
> 
> Trivia: bumped into this while reviewing something else, too many
> threes, you will have to fix the added reference up.

Argh! Fixed locally, thanks for catching it.

Best,

- Juri
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string
From: Rob Herring @ 2016-12-12 14:21 UTC (permalink / raw)
  To: Dongpo Li
  Cc: Mark Rutland, Michael Turquette, Stephen Boyd, Russell King,
	Zhangfei Gao, Yisen Zhuang, salil.mehta, David Miller,
	Arnd Bergmann, Andrew Lunn, Jiancheng Xue, benjamin.chenhao,
	caizhiyong, netdev, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <584E871D.7060200@hisilicon.com>

On Mon, Dec 12, 2016 at 5:16 AM, Dongpo Li <lidongpo@hisilicon.com> wrote:
> Hi Rob,
>
> On 2016/12/10 6:35, Rob Herring wrote:
>> On Mon, Dec 05, 2016 at 09:27:58PM +0800, Dongpo Li wrote:
>>> The "hix5hd2" is SoC name, add the generic ethernet driver name.
>>> The "hisi-gemac-v1" is the basic version and "hisi-gemac-v2" adds
>>> the SG/TXCSUM/TSO/UFO features.
>>>
>>> Signed-off-by: Dongpo Li <lidongpo@hisilicon.com>
>>> ---
>>>  .../devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt    |  9 +++++++--
>>>  drivers/net/ethernet/hisilicon/hix5hd2_gmac.c             | 15 +++++++++++----
>>>  2 files changed, 18 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>>> index 75d398b..75920f0 100644
>>> --- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>>> +++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
>>> @@ -1,7 +1,12 @@
>>>  Hisilicon hix5hd2 gmac controller
>>>
>>>  Required properties:
>>> -- compatible: should be "hisilicon,hix5hd2-gmac".
>>> +- compatible: should contain one of the following SoC strings:
>>> +    * "hisilicon,hix5hd2-gemac"
>>> +    * "hisilicon,hi3798cv200-gemac"
>>> +    and one of the following version string:
>>> +    * "hisilicon,hisi-gemac-v1"
>>> +    * "hisilicon,hisi-gemac-v2"
>>
>> What combinations are valid? I assume both chips don't have both v1 and
>> v2. 2 SoCs and 2 versions so far, I don't think there is much point to
>> have the v1 and v2 compatible strings.
>>
> The v1 and v2 are generic MAC compatible strings, many HiSilicon SoCs may
> use the same MAC version. For example,
> hix5hd2, hi3716cv200 SoCs use the v1 MAC version,
> hi3798cv200, hi3516a SoCs use the v2 MAC version,
> and there may be more SoCs added in future.
> So I think the generic compatible strings are okay here.
> Should I add the hi3716cv200, hi3516a SoCs compatible here?

Yes.

> Do you have any good advice?
>
>>>  - reg: specifies base physical address(s) and size of the device registers.
>>>    The first region is the MAC register base and size.
>>>    The second region is external interface control register.
>>> @@ -20,7 +25,7 @@ Required properties:
>>>
>>>  Example:
>>>      gmac0: ethernet@f9840000 {
>>> -            compatible = "hisilicon,hix5hd2-gmac";
>>> +            compatible = "hisilicon,hix5hd2-gemac", "hisilicon,hisi-gemac-v1";
>>
>> You can't just change compatible strings.
>>
> Okay, maybe I should name all the compatible string with the suffix "-gmac" instead of
> "-gemac". This can keep the compatible strings with the same suffix. Is this okay?
> Can I just add the generic compatible string without changing the SoCs compatible string?
> Like following:
>         gmac0: ethernet@f9840000 {
>  -              compatible = "hisilicon,hix5hd2-gmac";
>  +              compatible = "hisilicon,hix5hd2-gmac", "hisilicon,hisi-gmac-v1";

Yes, this is fine.

Rob

^ permalink raw reply

* Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Rob Herring @ 2016-12-12 14:47 UTC (permalink / raw)
  To: Benjamin Tissoires
  Cc: Jiri Kosina, Dmitry Torokhov, Doug Anderson, Brian Norris,
	Caesar Wang, open list:ARM/Rockchip SoC...,
	linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Mark Rutland
In-Reply-To: <20161212100110.GA13907-/m+UfqrgI5QNLKR9yMNcA1aTQe2KTcn/@public.gmane.org>

On Mon, Dec 12, 2016 at 4:01 AM, Benjamin Tissoires
<benjamin.tissoires-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Dec 12 2016 or thereabouts, Jiri Kosina wrote:
>> Given the timing (merge window being open) and given then NACK given by
>> Rob, I've now unapplied the patches (the for-4.10/i2c-hid branch is now
>> obsolete, and has been superseded by for-4.10/i2c-hid-nopower).
>>
>> However, this is mostly done in order to provide more time for discussion;
>> I still disagree with the reasoning behind the NACK.
>>
>
> To hopefully make things going forward a little bit, I was wondering
> over the week-end if we should not solve this particular issue by adding
> an intermediate platform DT node:
>
> instead of having:
> ---
>         i2c-hid-dev@2c {
>                 compatible = "hid-over-i2c";
>                 reg = <0x2c>;
>                 hid-descr-addr = <0x0020>;
>                 interrupt-parent = <&gpx3>;
>                 interrupts = <3 2>;
>                 vdd-supply = <sth>;
>                 init-delay-ms = <100>;
>         };
> ---
>
> we would have:
> ---
>         platform-i2c-hid@01 {
>                 compatible = "very-special-board-that-needs-firmware-quirks-and-delay-of-100ms";
>                 vdd-supply = <sth>;
>                 i2c-hid-dev@2c {
>                         compatible = "hid-over-i2c";
>                         reg = <0x2c>;
>                         hid-descr-addr = <0x0020>;
>                         interrupt-parent = <&gpx3>;
>                         interrupts = <3 2>;
>                 };
>         };
> ---
>
> If I am not wrong, the platform device should be initialized before
> i2c-hid get called, which allows to setup properly the vdd supply.
> On resume/suspend, the tree should be respected and we should be able to
> enable/disable power in the same fashion this patch provides.
>
> We could then extend this platform device at will without tinkering in
> i2c-hid and we could also handle the GPIOs, reset or whatever is
> required in the future through compatibles.
>
> Thoughts? yes? no? bullshit?

That is structuring the DT match your driver structure, not what the
h/w looks like. This would make sense if the device was multi-function
of which HID-over-I2C was one function. You could do what you describe
with a single node and the platform driver creates the hid-over-i2c
device. DT is not the only way to create devices.

Anyway, we're only debating this:

         i2c-hid-dev@2c {
                 compatible = "wacom,w9013", "hid-over-i2c";
                 reg = <0x2c>;
                 hid-descr-addr = <0x0020>;
                 interrupt-parent = <&gpx3>;
                 interrupts = <3 2>;
                 vdd-supply = <sth>;
                 init-delay-ms = <100>;
         };

vs.

         i2c-hid-dev@2c {
                 compatible = "hid-over-i2c";
                 reg = <0x2c>;
                 hid-descr-addr = <0x0020>;
                 interrupt-parent = <&gpx3>;
                 interrupts = <3 2>;
                 vdd-supply = <sth>;
                 init-delay-ms = <100>;
         };

My only other nit is use "post-power-on-delay-ms" which is already a
defined property name rather than "init-delay-ms".

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH v2 0/2] Add support for the DW IP Prototyping Kits for MIPI CSI-2 Host
From: Ramiro Oliveira @ 2016-12-12 15:00 UTC (permalink / raw)
  To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	mchehab-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-media-u79uwXL29TY76Z2rM5mHXA
  Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
	linux-0h96xk9xTtrk1uMJSBkQmQ, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
	laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw, arnd-r2nGTMty4D4,
	sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
	tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
	minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
	jean-christophe.trotin-qxv4g6HH51o,
	andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
	simon.horman-wFxRvT7yatFl57MIdRCFDg,
	songjun.wu-UWL1GkI3JZL3oGB3hsPCZA, bparrot-l0cyMroinI0,
	CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w,
	Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w

This patchset adds support for the DW CSI-2 Host IPK. These kits are intended
to help in the bringup of IP titles developed by Synopsys.

This is the second version of this patchset.

v2: 
 - Add more detailed descriptions in the DT documentation
 - Add binding examples to DT documentation
 - Remove unnecessary debug structures
 - Remove unused fields in structures
 - Change variable types
 - Remove unused functions
 - Declare functions as static
 - Remove some prints
 - Add missing newlines.


Ramiro Oliveira (2):
  Add Documentation for Media Device, Video Device, and Synopsys DW MIPI
    CSI-2 Host
  Support for basic DW CSI-2 Host IPK funcionality

 .../devicetree/bindings/media/snps,dw-mipi-csi.txt |  27 +
 .../devicetree/bindings/media/snps,plat-ipk.txt    |   9 +
 .../bindings/media/snps,video-device.txt           |  12 +
 MAINTAINERS                                        |   7 +
 drivers/media/platform/Kconfig                     |   1 +
 drivers/media/platform/Makefile                    |   2 +
 drivers/media/platform/dwc/Kconfig                 |  36 +
 drivers/media/platform/dwc/Makefile                |   3 +
 drivers/media/platform/dwc/dw_mipi_csi.c           | 647 ++++++++++++++++
 drivers/media/platform/dwc/dw_mipi_csi.h           | 180 +++++
 drivers/media/platform/dwc/plat_ipk.c              | 818 +++++++++++++++++++++
 drivers/media/platform/dwc/plat_ipk.h              | 101 +++
 drivers/media/platform/dwc/plat_ipk_video.h        |  97 +++
 drivers/media/platform/dwc/video_device.c          | 707 ++++++++++++++++++
 drivers/media/platform/dwc/video_device.h          |  85 +++
 15 files changed, 2732 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
 create mode 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt
 create mode 100644 Documentation/devicetree/bindings/media/snps,video-device.txt
 create mode 100644 drivers/media/platform/dwc/Kconfig
 create mode 100644 drivers/media/platform/dwc/Makefile
 create mode 100644 drivers/media/platform/dwc/dw_mipi_csi.c
 create mode 100644 drivers/media/platform/dwc/dw_mipi_csi.h
 create mode 100644 drivers/media/platform/dwc/plat_ipk.c
 create mode 100644 drivers/media/platform/dwc/plat_ipk.h
 create mode 100644 drivers/media/platform/dwc/plat_ipk_video.h
 create mode 100644 drivers/media/platform/dwc/video_device.c
 create mode 100644 drivers/media/platform/dwc/video_device.h

-- 
2.10.2


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

^ permalink raw reply

* [PATCH v2 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host
From: Ramiro Oliveira @ 2016-12-12 15:00 UTC (permalink / raw)
  To: robh+dt, mark.rutland, mchehab, devicetree, linux-kernel,
	linux-media
  Cc: davem, gregkh, geert+renesas, akpm, linux, hverkuil,
	laurent.pinchart+renesas, arnd, sudipm.mukherjee, tiffany.lin,
	minghsiu.tsai, jean-christophe.trotin, andrew-ct.chen,
	simon.horman, songjun.wu, bparrot, CARLOS.PALMINHA,
	Ramiro.Oliveira
In-Reply-To: <cover.1481548484.git.roliveir@synopsys.com>

Create device tree bindings documentation for Media and Video Device, as well
as the DW MIPI CSI-2 Host.

Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
---
 .../devicetree/bindings/media/snps,dw-mipi-csi.txt |  37 ++++++++
 .../devicetree/bindings/media/snps,plat-ipk.txt    | 105 +++++++++++++++++++++
 2 files changed, 142 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
 create mode 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt

diff --git a/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
new file mode 100644
index 0000000..1caa652
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
@@ -0,0 +1,37 @@
+Synopsys DesignWare CSI-2 Host controller
+
+Description
+-----------
+
+This HW block is used to receive image coming from an MIPI CSI-2 compatible
+camera.
+
+Required properties:
+- compatible: shall be "snps,dw-mipi-csi"
+- reg		: physical base address and size of the device memory mapped
+  registers;
+- interrupts	: CSI-2 Host interrupt
+- data-lanes    : Number of lanes to be used
+- output-type   : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2) These
+  values choose which of the Core outputs will be used, it can be Image Data
+  Interface or Image Pixel Interface.
+- phys, phy-names: List of one PHY specifier and identifier string (as defined
+  in Documentation/devicetree/bindings/phy/phy-bindings.txt). This PHY is a MIPI
+  DPHY working in RX mode.
+
+Optional properties(if in IPI mode):
+- ipi-mode 	: Mode to be used when in IPI(Camera -> 0 or Automatic -> 1)
+  This property defines if the controller will use the video timings available
+  in the video stream or if it will use pre-defined ones.
+- ipi-color-mode: Bus depth to be used in IPI (48 bits -> 0 or 16 bits -> 1)
+  This property defines the width of the IPI bus.
+- ipi-auto-flush: Data auto-flush (1 -> Yes or 0 -> No). This property defines
+  if the data is automatically flushed in each vsync or if this process is done
+  manually
+- virtual-channel: Virtual channel where data is present when in IPI mode. This
+  property chooses the virtual channel which IPI will use to retrieve the video
+  stream.
+
+The per-board settings:
+ - port sub-node describing a single endpoint connected to the dw-mipi-csi
+   as described in video-interfaces.txt[1].
diff --git a/Documentation/devicetree/bindings/media/snps,plat-ipk.txt b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
new file mode 100644
index 0000000..50e9279
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
@@ -0,0 +1,105 @@
+Synopsys DesignWare CSI-2 Host IPK Media Device
+
+The Synopsys DesignWare CSI-2 Host IPK subsystem comprises of multiple
+sub-devices represented by separate device tree nodes. Currently this includes:
+plat-ipk, video-device, and dw-mipi-csi.
+
+The sub-subdevices are defined as child nodes of the common 'camera' node which
+also includes common properties of the whole subsystem not really specific to
+any single sub-device.
+
+Common 'camera' node
+--------------------
+
+Required properties:
+
+- compatible: must be "snps,plat-ipk", "simple-bus"
+
+The 'camera' node must include at least one 'video-device' and one 'dw-mipi-csi'
+child node.
+
+'video-device' device nodes
+-------------------
+
+Required properties:
+
+- compatible: "snps,video-device"
+- dmas, dma-names: List of one DMA specifier and identifier string (as defined
+  in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
+  requires a DMA channel with the identifier string set to "port" followed by
+  the port index.
+
+Image sensor nodes
+------------------
+
+The sensor device nodes should be added to their control bus controller (e.g.
+I2C0) nodes and linked to a port node in the dw-mipi-csi,using the common video
+interfaces bindings, defined in video-interfaces.txt.
+
+Example:
+
+	i2c@0x02000 {
+			compatible = "snps,designware-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x02000 0x100>;
+			clock-frequency = <400000>;
+			clocks = <&i2cclk>;
+			interrupts =<0>;
+			ov: camera@0x36 {
+				compatible = "ovti,ov5647";
+				reg = <0x36>;
+				port {
+					camera_1: endpoint {
+						remote-endpoint = <&csi1_ep1>;
+						clock-lanes = <0>;
+						data-lanes = <1 2 >;
+					};
+				};
+			};
+		};
+
+
+	camera {
+		compatible = "snps,plat-ipk", "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+			video_device: video-device@0x10000 {
+				compatible = "snps,video-device";
+				dmas = <&axi_vdma_0 0>;
+				dma-names = "vdma0";
+			};
+
+
+			csi2_1: csi2@0x03000 {
+				compatible = "snps,dw-mipi-csi";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = < 0x03000 0x7FF>;
+				interrupts = <2>;
+				data-lanes = <2>;
+				output-type = <2>;
+
+				phys = <&mipi_phy_ctrl1 0>;
+				phy-names = "csi2-dphy";
+
+				/*IPI Related Configurations*/
+				ipi-mode = <0>;
+				ipi-color-mode = <0>;
+				ipi-auto-flush = <1>;
+				virtual-channel = <0>;
+
+				/* Camera MIPI CSI-2 (CSI1) */
+				port@1 {
+					reg = <1>;
+					csi1_ep1: endpoint {
+						remote-endpoint = <&camera_1>;
+						data-lanes = <1 2>;
+						};
+				};
+			};
+		};
+	};
+
+The dw-mipi-csi device binding is defined in snps,dw-mipi-csi.txt.
-- 
2.10.2

^ permalink raw reply related

* [PATCH v2 2/2] Support for DW CSI-2 Host IPK
From: Ramiro Oliveira @ 2016-12-12 15:00 UTC (permalink / raw)
  To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	mchehab-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-media-u79uwXL29TY76Z2rM5mHXA
  Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
	linux-0h96xk9xTtrk1uMJSBkQmQ, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
	laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw, arnd-r2nGTMty4D4,
	sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
	tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
	minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
	jean-christophe.trotin-qxv4g6HH51o,
	andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
	simon.horman-wFxRvT7yatFl57MIdRCFDg,
	songjun.wu-UWL1GkI3JZL3oGB3hsPCZA, bparrot-l0cyMroinI0,
	CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w,
	Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <48a46d2d60fff723e322fdbfb29d533c2d0f5637.1481554324.git.roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>

Add support for the DesignWare CSI-2 Host IP Prototyping Kit

Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
---
 MAINTAINERS                                 |   7 +
 drivers/media/platform/Kconfig              |   1 +
 drivers/media/platform/Makefile             |   2 +
 drivers/media/platform/dwc/Kconfig          |  36 ++
 drivers/media/platform/dwc/Makefile         |   3 +
 drivers/media/platform/dwc/dw_mipi_csi.c    | 647 ++++++++++++++++++++++
 drivers/media/platform/dwc/dw_mipi_csi.h    | 180 ++++++
 drivers/media/platform/dwc/plat_ipk.c       | 818 ++++++++++++++++++++++++++++
 drivers/media/platform/dwc/plat_ipk.h       | 101 ++++
 drivers/media/platform/dwc/plat_ipk_video.h |  97 ++++
 drivers/media/platform/dwc/video_device.c   | 707 ++++++++++++++++++++++++
 drivers/media/platform/dwc/video_device.h   |  85 +++
 12 files changed, 2684 insertions(+)
 create mode 100644 drivers/media/platform/dwc/Kconfig
 create mode 100644 drivers/media/platform/dwc/Makefile
 create mode 100644 drivers/media/platform/dwc/dw_mipi_csi.c
 create mode 100644 drivers/media/platform/dwc/dw_mipi_csi.h
 create mode 100644 drivers/media/platform/dwc/plat_ipk.c
 create mode 100644 drivers/media/platform/dwc/plat_ipk.h
 create mode 100644 drivers/media/platform/dwc/plat_ipk_video.h
 create mode 100644 drivers/media/platform/dwc/video_device.c
 create mode 100644 drivers/media/platform/dwc/video_device.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 72e828a..73250b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10651,6 +10651,13 @@ S:	Maintained
 F:	drivers/staging/media/st-cec/
 F:	Documentation/devicetree/bindings/media/stih-cec.txt
 
+SYNOPSYS DESIGNWARE CSI-2 HOST IPK DRIVER
+M:	Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
+L:	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+T:	git git://linuxtv.org/media_tree.git
+S:	Maintained
+F:	drivers/media/platform/dwc/
+
 SYNOPSYS DESIGNWARE DMAC DRIVER
 M:	Viresh Kumar <vireshk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
 M:	Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421..7b99ba3 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -120,6 +120,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/dwc/Kconfig"
 
 config VIDEO_TI_CAL
 	tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 5b3cb27..d84b1de 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -62,6 +62,8 @@ obj-$(CONFIG_VIDEO_RCAR_VIN)		+= rcar-vin/
 
 obj-$(CONFIG_VIDEO_ATMEL_ISC)		+= atmel/
 
+obj-$(CONFIG_VIDEO_DWC)			+= dwc/
+
 ccflags-y += -I$(srctree)/drivers/media/i2c
 
 obj-$(CONFIG_VIDEO_MEDIATEK_VPU)	+= mtk-vpu/
diff --git a/drivers/media/platform/dwc/Kconfig b/drivers/media/platform/dwc/Kconfig
new file mode 100644
index 0000000..fb8533b
--- /dev/null
+++ b/drivers/media/platform/dwc/Kconfig
@@ -0,0 +1,36 @@
+config VIDEO_DWC
+	bool "Designware Cores CSI-2 IPK (EXPERIMENTAL)"
+	depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA
+	help
+	  Say Y here to enable support for the DesignWare Cores CSI-2 Host IP
+	  Prototyping Kit.
+
+if VIDEO_DWC
+config DWC_PLATFORM
+	tristate "SNPS DWC MIPI CSI2 Host"
+	depends on VIDEO_DWC
+	help
+	  This is the V4L2 plaftorm driver driver for the DWC CSI-2 HOST IPK
+
+	  To compile this driver as a module, choose M here
+
+
+config DWC_MIPI_CSI2_HOST
+	tristate "SNPS DWC MIPI CSI2 Host"
+	select GENERIC_PHY
+	depends on VIDEO_DWC
+	help
+	  This is a V4L2 driver for SNPS DWC MIPI-CSI2
+
+	  To compile this driver as a module, choose M here
+
+config DWC_VIDEO_DEVICE
+	tristate "DWC VIDEO DEVICE"
+	select VIDEOBUF2_VMALLOC
+	select VIDEOBUF2_DMA_CONTIG
+	depends on VIDEO_DWC
+	help
+	  This is a V4L2 driver for SNPS Video device
+	  To compile this driver as a module, choose M here
+
+endif # VIDEO_DWC
diff --git a/drivers/media/platform/dwc/Makefile b/drivers/media/platform/dwc/Makefile
new file mode 100644
index 0000000..75c74b7
--- /dev/null
+++ b/drivers/media/platform/dwc/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_DWC_PLATFORM)		+= plat_ipk.o
+obj-$(CONFIG_DWC_MIPI_CSI2_HOST)	+= dw_mipi_csi.o
+obj-$(CONFIG_DWC_VIDEO_DEVICE)		+= video_device.o
diff --git a/drivers/media/platform/dwc/dw_mipi_csi.c b/drivers/media/platform/dwc/dw_mipi_csi.c
new file mode 100644
index 0000000..6515afa
--- /dev/null
+++ b/drivers/media/platform/dwc/dw_mipi_csi.c
@@ -0,0 +1,647 @@
+/*
+ * DWC MIPI CSI-2 Host device driver
+ *
+ * Copyright (C) 2016 Synopsys, Inc. All rights reserved.
+ * Author: Ramiro Oliveira <ramiro.oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include "dw_mipi_csi.h"
+
+/**
+ * @short Video formats supported by the MIPI CSI-2
+ */
+static const struct mipi_fmt dw_mipi_csi_formats[] = {
+	{
+		/* RAW 8 */
+		.code = MEDIA_BUS_FMT_SBGGR8_1X8,
+		.depth = 8,
+	},
+	{
+		/* RAW 10 */
+		.code = MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE,
+		.depth = 10,
+	},
+	{
+		/* RGB 565 */
+		.code = MEDIA_BUS_FMT_RGB565_2X8_BE,
+		.depth = 16,
+	},
+	{
+		/* BGR 565 */
+		.code = MEDIA_BUS_FMT_RGB565_2X8_LE,
+		.depth = 16,
+	},
+	{
+		/* RGB 888 */
+		.code = MEDIA_BUS_FMT_RGB888_2X12_LE,
+		.depth = 24,
+	},
+	{
+		/* BGR 888 */
+		.code = MEDIA_BUS_FMT_RGB888_2X12_BE,
+		.depth = 24,
+	},
+};
+
+static struct mipi_csi_dev *sd_to_mipi_csi_dev(struct v4l2_subdev *sdev)
+{
+	return container_of(sdev, struct mipi_csi_dev, sd);
+}
+
+static void dw_mipi_csi_write(struct mipi_csi_dev *dev,
+		  unsigned int address, unsigned int data)
+{
+	iowrite32(data, dev->base_address + address);
+}
+
+static u32 dw_mipi_csi_read(struct mipi_csi_dev *dev, unsigned long address)
+{
+	return ioread32(dev->base_address + address);
+}
+
+static void dw_mipi_csi_write_part(struct mipi_csi_dev *dev,
+		       unsigned long address, unsigned long data,
+		       unsigned char shift, unsigned char width)
+{
+	u32 mask = (1 << width) - 1;
+	u32 temp = dw_mipi_csi_read(dev, address);
+
+	temp &= ~(mask << shift);
+	temp |= (data & mask) << shift;
+	dw_mipi_csi_write(dev, address, temp);
+}
+
+static const struct mipi_fmt *
+find_dw_mipi_csi_format(struct v4l2_mbus_framefmt *mf)
+{
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(dw_mipi_csi_formats); i++)
+		if (mf->code == dw_mipi_csi_formats[i].code)
+			return &dw_mipi_csi_formats[i];
+	return NULL;
+}
+
+static void dw_mipi_csi_reset(struct mipi_csi_dev *dev)
+{
+	dw_mipi_csi_write(dev, R_CSI2_CTRL_RESETN, 0);
+	dw_mipi_csi_write(dev, R_CSI2_CTRL_RESETN, 1);
+}
+
+static int dw_mipi_csi_mask_irq_power_off(struct mipi_csi_dev *dev)
+{
+	/* set only one lane (lane 0) as active (ON) */
+	dw_mipi_csi_write(dev, R_CSI2_N_LANES, 0);
+
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_PHY_FATAL, 0);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_PKT_FATAL, 0);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_FRAME_FATAL, 0);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_PHY, 0);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_PKT, 0);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_LINE, 0);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_IPI, 0);
+
+	dw_mipi_csi_write(dev, R_CSI2_CTRL_RESETN, 0);
+
+	return 0;
+
+}
+
+static int dw_mipi_csi_hw_stdby(struct mipi_csi_dev *dev)
+{
+	/* set only one lane (lane 0) as active (ON) */
+	dw_mipi_csi_reset(dev);
+
+	dw_mipi_csi_write(dev, R_CSI2_N_LANES, 0);
+
+	phy_init(dev->phy);
+
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_PHY_FATAL, 0xFFFFFFFF);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_PKT_FATAL, 0xFFFFFFFF);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_FRAME_FATAL, 0xFFFFFFFF);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_PHY, 0xFFFFFFFF);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_PKT, 0xFFFFFFFF);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_LINE, 0xFFFFFFFF);
+	dw_mipi_csi_write(dev, R_CSI2_MASK_INT_IPI, 0xFFFFFFFF);
+
+	return 0;
+
+}
+
+static void dw_mipi_csi_set_ipi_fmt(struct mipi_csi_dev *csi_dev)
+{
+	struct device *dev = &csi_dev->pdev->dev;
+
+	switch (csi_dev->fmt->code) {
+	case MEDIA_BUS_FMT_RGB565_2X8_BE:
+	case MEDIA_BUS_FMT_RGB565_2X8_LE:
+		dw_mipi_csi_write(csi_dev, R_CSI2_IPI_DATA_TYPE, CSI_2_RGB565);
+		dev_dbg(dev, "DT: RGB 565");
+		break;
+
+	case MEDIA_BUS_FMT_RGB888_2X12_LE:
+	case MEDIA_BUS_FMT_RGB888_2X12_BE:
+		dw_mipi_csi_write(csi_dev, R_CSI2_IPI_DATA_TYPE, CSI_2_RGB888);
+		dev_dbg(dev, "DT: RGB 888");
+		break;
+	case MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE:
+		dw_mipi_csi_write(csi_dev, R_CSI2_IPI_DATA_TYPE, CSI_2_RAW10);
+		dev_dbg(dev, "DT: RAW 10");
+		break;
+	case MEDIA_BUS_FMT_SBGGR8_1X8:
+		dw_mipi_csi_write(csi_dev, R_CSI2_IPI_DATA_TYPE, CSI_2_RAW8);
+		dev_dbg(dev, "DT: RAW 8");
+		break;
+	default:
+		dw_mipi_csi_write(csi_dev, R_CSI2_IPI_DATA_TYPE, CSI_2_RGB565);
+		dev_dbg(dev, "Error");
+		break;
+	}
+}
+
+static void __dw_mipi_csi_fill_timings(struct mipi_csi_dev *dev,
+			   const struct v4l2_bt_timings *bt)
+{
+
+	if (bt == NULL)
+		return;
+
+	dev->hw.hsa = bt->hsync;
+	dev->hw.hbp = bt->hbackporch;
+	dev->hw.hsd = bt->hsync;
+	dev->hw.htotal = bt->height + bt->vfrontporch +
+	    bt->vsync + bt->vbackporch;
+	dev->hw.vsa = bt->vsync;
+	dev->hw.vbp = bt->vbackporch;
+	dev->hw.vfp = bt->vfrontporch;
+	dev->hw.vactive = bt->height;
+}
+
+static void dw_mipi_csi_start(struct mipi_csi_dev *csi_dev)
+{
+	const struct v4l2_bt_timings *bt = &v4l2_dv_timings_presets[0].bt;
+	struct device *dev = &csi_dev->pdev->dev;
+
+	__dw_mipi_csi_fill_timings(csi_dev, bt);
+
+	dw_mipi_csi_write(csi_dev, R_CSI2_N_LANES, (csi_dev->hw.num_lanes - 1));
+	dev_dbg(dev, "N Lanes: %d\n", csi_dev->hw.num_lanes);
+
+	/*IPI Related Configuration */
+	if ((csi_dev->hw.output_type == IPI_OUT)
+	    || (csi_dev->hw.output_type == BOTH_OUT)) {
+
+		dw_mipi_csi_write_part(csi_dev, R_CSI2_IPI_MODE,
+					csi_dev->hw.ipi_mode, 0, 1);
+		dev_dbg(dev, "IPI MODE: %d\n", csi_dev->hw.ipi_mode);
+
+		dw_mipi_csi_write_part(csi_dev, R_CSI2_IPI_MODE,
+				       csi_dev->hw.ipi_color_mode, 8, 1);
+		dev_dbg(dev, "Color Mode: %d\n", csi_dev->hw.ipi_color_mode);
+
+		dw_mipi_csi_write(csi_dev, R_CSI2_IPI_VCID,
+					csi_dev->hw.virtual_ch);
+		dev_dbg(dev, "Virtual Channel: %d\n", csi_dev->hw.virtual_ch);
+
+		dw_mipi_csi_write_part(csi_dev, R_CSI2_IPI_MEM_FLUSH,
+				       csi_dev->hw.ipi_auto_flush, 8, 1);
+		dev_dbg(dev, "Auto-flush: %d\n", csi_dev->hw.ipi_auto_flush);
+
+		dw_mipi_csi_write(csi_dev, R_CSI2_IPI_HSA_TIME,
+					csi_dev->hw.hsa);
+		dev_dbg(dev, "HSA: %d\n", csi_dev->hw.hsa);
+
+		dw_mipi_csi_write(csi_dev, R_CSI2_IPI_HBP_TIME,
+					csi_dev->hw.hbp);
+		dev_dbg(dev, "HBP: %d\n", csi_dev->hw.hbp);
+
+		dw_mipi_csi_write(csi_dev, R_CSI2_IPI_HSD_TIME,
+					csi_dev->hw.hsd);
+		dev_dbg(dev, "HSD: %d\n", csi_dev->hw.hsd);
+
+		if (csi_dev->hw.ipi_mode == AUTO_TIMING) {
+			dw_mipi_csi_write(csi_dev, R_CSI2_IPI_HLINE_TIME,
+					  csi_dev->hw.htotal);
+			dev_dbg(dev, "H total: %d\n", csi_dev->hw.htotal);
+
+			dw_mipi_csi_write(csi_dev, R_CSI2_IPI_VSA_LINES,
+					  csi_dev->hw.vsa);
+			dev_dbg(dev, "VSA: %d\n", csi_dev->hw.vsa);
+
+			dw_mipi_csi_write(csi_dev, R_CSI2_IPI_VBP_LINES,
+					  csi_dev->hw.vbp);
+			dev_dbg(dev, "VBP: %d\n", csi_dev->hw.vbp);
+
+			dw_mipi_csi_write(csi_dev, R_CSI2_IPI_VFP_LINES,
+					  csi_dev->hw.vfp);
+			dev_dbg(dev, "VFP: %d\n", csi_dev->hw.vfp);
+
+			dw_mipi_csi_write(csi_dev, R_CSI2_IPI_VACTIVE_LINES,
+					  csi_dev->hw.vactive);
+			dev_dbg(dev, "V Active: %d\n", csi_dev->hw.vactive);
+		}
+	}
+
+	phy_power_on(csi_dev->phy);
+}
+
+static int dw_mipi_csi_enum_mbus_code(struct v4l2_subdev *sd,
+					struct v4l2_subdev_pad_config *cfg,
+					struct v4l2_subdev_mbus_code_enum *code)
+{
+	if (code->index >= ARRAY_SIZE(dw_mipi_csi_formats))
+		return -EINVAL;
+
+	code->code = dw_mipi_csi_formats[code->index].code;
+	return 0;
+}
+
+static struct mipi_fmt const *
+dw_mipi_csi_try_format(struct v4l2_mbus_framefmt *mf)
+{
+	struct mipi_fmt const *fmt;
+
+	fmt = find_dw_mipi_csi_format(mf);
+	if (fmt == NULL)
+		fmt = &dw_mipi_csi_formats[0];
+
+	mf->code = fmt->code;
+	return fmt;
+}
+
+static struct v4l2_mbus_framefmt *
+__dw_mipi_csi_get_format(struct mipi_csi_dev *dev,
+			 struct v4l2_subdev_pad_config *cfg,
+			 enum v4l2_subdev_format_whence which)
+{
+	if (which == V4L2_SUBDEV_FORMAT_TRY)
+		return cfg ? v4l2_subdev_get_try_format(&dev->sd, cfg,
+							0) : NULL;
+
+	return &dev->format;
+}
+
+static int
+dw_mipi_csi_set_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config *cfg,
+		    struct v4l2_subdev_format *fmt)
+{
+	struct mipi_csi_dev *dev = sd_to_mipi_csi_dev(sd);
+	struct mipi_fmt const *dev_fmt;
+	struct v4l2_mbus_framefmt *mf;
+	unsigned int i = 0;
+	const struct v4l2_bt_timings *bt_r = &v4l2_dv_timings_presets[0].bt;
+
+	mf = __dw_mipi_csi_get_format(dev, cfg, fmt->which);
+
+	dev_fmt = dw_mipi_csi_try_format(&fmt->format);
+	if (dev_fmt) {
+		*mf = fmt->format;
+		if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE)
+			dev->fmt = dev_fmt;
+		dw_mipi_csi_set_ipi_fmt(dev);
+	}
+	while (v4l2_dv_timings_presets[i].bt.width) {
+		const struct v4l2_bt_timings *bt =
+		    &v4l2_dv_timings_presets[i].bt;
+		if (mf->width == bt->width && mf->height == bt->width) {
+			__dw_mipi_csi_fill_timings(dev, bt);
+			return 0;
+		}
+		i++;
+	}
+
+	__dw_mipi_csi_fill_timings(dev, bt_r);
+	return 0;
+
+}
+
+static int
+dw_mipi_csi_get_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_pad_config *cfg,
+		    struct v4l2_subdev_format *fmt)
+{
+	struct mipi_csi_dev *dev = sd_to_mipi_csi_dev(sd);
+	struct v4l2_mbus_framefmt *mf;
+
+	mf = __dw_mipi_csi_get_format(dev, cfg, fmt->which);
+	if (!mf)
+		return -EINVAL;
+
+	mutex_lock(&dev->lock);
+	fmt->format = *mf;
+	mutex_unlock(&dev->lock);
+	return 0;
+}
+
+static int
+dw_mipi_csi_s_power(struct v4l2_subdev *sd, int on)
+{
+	struct mipi_csi_dev *dev = sd_to_mipi_csi_dev(sd);
+
+	if (on) {
+		dw_mipi_csi_hw_stdby(dev);
+		dw_mipi_csi_start(dev);
+	} else {
+		dw_mipi_csi_mask_irq_power_off(dev);
+	}
+
+	return 0;
+}
+
+static int
+dw_mipi_csi_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+	struct v4l2_mbus_framefmt *format =
+	    v4l2_subdev_get_try_format(sd, fh->pad, 0);
+
+	format->colorspace = V4L2_COLORSPACE_SRGB;
+	format->code = dw_mipi_csi_formats[0].code;
+	format->width = MIN_WIDTH;
+	format->height = MIN_HEIGHT;
+	format->field = V4L2_FIELD_NONE;
+
+	return 0;
+}
+
+static const struct v4l2_subdev_internal_ops dw_mipi_csi_sd_internal_ops = {
+	.open = dw_mipi_csi_open,
+};
+
+static struct v4l2_subdev_core_ops dw_mipi_csi_core_ops = {
+	.s_power = dw_mipi_csi_s_power,
+};
+
+static struct v4l2_subdev_pad_ops dw_mipi_csi_pad_ops = {
+	.enum_mbus_code = dw_mipi_csi_enum_mbus_code,
+	.get_fmt = dw_mipi_csi_get_fmt,
+	.set_fmt = dw_mipi_csi_set_fmt,
+};
+
+static struct v4l2_subdev_ops dw_mipi_csi_subdev_ops = {
+	.core = &dw_mipi_csi_core_ops,
+	.pad = &dw_mipi_csi_pad_ops,
+};
+
+static irqreturn_t
+dw_mipi_csi_irq1(int irq, void *dev_id)
+{
+	struct mipi_csi_dev *csi_dev = dev_id;
+	u32 global_int_status, i_sts;
+	unsigned long flags;
+	struct device *dev = &csi_dev->pdev->dev;
+
+	global_int_status = dw_mipi_csi_read(csi_dev, R_CSI2_INTERRUPT);
+	spin_lock_irqsave(&csi_dev->slock, flags);
+
+	if (global_int_status & CSI2_INT_PHY_FATAL) {
+		i_sts = dw_mipi_csi_read(csi_dev, R_CSI2_INT_PHY_FATAL);
+		dev_dbg_ratelimited(dev, "CSI INT PHY FATAL: %08X\n", i_sts);
+	}
+
+	if (global_int_status & CSI2_INT_PKT_FATAL) {
+		i_sts = dw_mipi_csi_read(csi_dev, R_CSI2_INT_PKT_FATAL);
+		dev_dbg_ratelimited(dev, "CSI INT PKT FATAL: %08X\n", i_sts);
+	}
+
+	if (global_int_status & CSI2_INT_FRAME_FATAL) {
+		i_sts = dw_mipi_csi_read(csi_dev, R_CSI2_INT_FRAME_FATAL);
+		dev_dbg_ratelimited(dev, "CSI INT FRAME FATAL: %08X\n", i_sts);
+	}
+
+	if (global_int_status & CSI2_INT_PHY) {
+		i_sts = dw_mipi_csi_read(csi_dev, R_CSI2_INT_PHY);
+		dev_dbg_ratelimited(dev, "CSI INT PHY: %08X\n", i_sts);
+	}
+
+	if (global_int_status & CSI2_INT_PKT) {
+		i_sts = dw_mipi_csi_read(csi_dev, R_CSI2_INT_PKT);
+		dev_dbg_ratelimited(dev, "CSI INT PKT: %08X\n", i_sts);
+	}
+
+	if (global_int_status & CSI2_INT_LINE) {
+		i_sts = dw_mipi_csi_read(csi_dev, R_CSI2_INT_LINE);
+		dev_dbg_ratelimited(dev, "CSI INT LINE: %08X\n", i_sts);
+	}
+
+	if (global_int_status & CSI2_INT_IPI) {
+		i_sts = dw_mipi_csi_read(csi_dev, R_CSI2_INT_IPI);
+		dev_dbg_ratelimited(dev, "CSI INT IPI: %08X\n", i_sts);
+	}
+	spin_unlock_irqrestore(&csi_dev->slock, flags);
+	return IRQ_HANDLED;
+}
+
+static int
+dw_mipi_csi_parse_dt(struct platform_device *pdev, struct mipi_csi_dev *dev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	int reg;
+	int ret = 0;
+
+	/* Device tree information */
+	ret = of_property_read_u32(node, "data-lanes", &dev->hw.num_lanes);
+	if (ret) {
+		dev_err(&pdev->dev, "Couldn't read data-lanes\n");
+		return ret;
+	}
+
+	ret = of_property_read_u32(node, "output-type", &dev->hw.output_type);
+	if (ret) {
+		dev_err(&pdev->dev, "Couldn't read output-type\n");
+		return ret;
+	}
+
+	ret = of_property_read_u32(node, "ipi-mode", &dev->hw.ipi_mode);
+	if (ret) {
+		dev_err(&pdev->dev, "Couldn't read ipi-mode\n");
+		return ret;
+	}
+
+	ret =
+	    of_property_read_u32(node, "ipi-auto-flush",
+				 &dev->hw.ipi_auto_flush);
+	if (ret) {
+		dev_err(&pdev->dev, "Couldn't read ipi-auto-flush\n");
+		return ret;
+	}
+
+	ret =
+	    of_property_read_u32(node, "ipi-color-mode",
+				 &dev->hw.ipi_color_mode);
+	if (ret) {
+		dev_err(&pdev->dev, "Couldn't read ipi-color-mode\n");
+		return ret;
+	}
+
+	ret =
+	    of_property_read_u32(node, "virtual-channel", &dev->hw.virtual_ch);
+	if (ret) {
+		dev_err(&pdev->dev, "Couldn't read virtual-channel\n");
+		return ret;
+	}
+
+	node = of_get_child_by_name(node, "port");
+	if (!node)
+		return -EINVAL;
+
+	ret = of_property_read_u32(node, "reg", &reg);
+	if (ret) {
+		dev_err(&pdev->dev, "Couldn't read reg value\n");
+		return ret;
+	}
+	dev->index = reg - 1;
+
+	if (dev->index >= CSI_MAX_ENTITIES)
+		return -ENXIO;
+
+	return 0;
+}
+
+static const struct of_device_id dw_mipi_csi_of_match[];
+
+/**
+ * @short Initialization routine - Entry point of the driver
+ * @param[in] pdev pointer to the platform device structure
+ * @return 0 on success and a negative number on failure
+ * Refer to Linux errors.
+ */
+static int mipi_csi_probe(struct platform_device *pdev)
+{
+	const struct of_device_id *of_id;
+	struct device *dev = &pdev->dev;
+	struct resource *res = NULL;
+	struct mipi_csi_dev *mipi_csi;
+	int ret = -ENOMEM;
+
+	mipi_csi = devm_kzalloc(dev, sizeof(*mipi_csi), GFP_KERNEL);
+	if (!dev)
+		return -ENOMEM;
+
+	mutex_init(&mipi_csi->lock);
+	spin_lock_init(&mipi_csi->slock);
+	mipi_csi->pdev = pdev;
+
+	of_id = of_match_node(dw_mipi_csi_of_match, dev->of_node);
+	if (WARN_ON(of_id == NULL))
+		return -EINVAL;
+
+	ret = dw_mipi_csi_parse_dt(pdev, mipi_csi);
+	if (ret < 0)
+		return ret;
+
+	mipi_csi->phy = devm_phy_get(dev, "csi2-dphy");
+	if (IS_ERR(mipi_csi->phy)) {
+		dev_err(dev, "No DPHY available\n");
+		return PTR_ERR(mipi_csi->phy);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mipi_csi->base_address = devm_ioremap_resource(dev, res);
+
+	if (IS_ERR(mipi_csi->base_address)) {
+		dev_err(dev, "Base address not set.\n");
+		return PTR_ERR(mipi_csi->base_address);
+	}
+
+	mipi_csi->ctrl_irq_number = platform_get_irq(pdev, 0);
+	if (mipi_csi->ctrl_irq_number <= 0) {
+		dev_err(dev, "IRQ number not set.\n");
+		return mipi_csi->ctrl_irq_number;
+	}
+
+	ret = devm_request_irq(dev, mipi_csi->ctrl_irq_number,
+			       dw_mipi_csi_irq1, IRQF_SHARED,
+			       dev_name(dev), mipi_csi);
+	if (ret) {
+		dev_err(dev, "IRQ failed\n");
+		goto end;
+	}
+
+	v4l2_subdev_init(&mipi_csi->sd, &dw_mipi_csi_subdev_ops);
+	mipi_csi->sd.owner = THIS_MODULE;
+	snprintf(mipi_csi->sd.name, sizeof(mipi_csi->sd.name), "%s.%d",
+		 CSI_DEVICE_NAME, mipi_csi->index);
+	mipi_csi->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+	mipi_csi->fmt = &dw_mipi_csi_formats[0];
+
+	mipi_csi->format.code = dw_mipi_csi_formats[0].code;
+	mipi_csi->format.width = MIN_WIDTH;
+	mipi_csi->format.height = MIN_HEIGHT;
+
+	mipi_csi->sd.entity.function = MEDIA_ENT_F_IO_V4L;
+	mipi_csi->pads[CSI_PAD_SINK].flags = MEDIA_PAD_FL_SINK;
+	mipi_csi->pads[CSI_PAD_SOURCE].flags = MEDIA_PAD_FL_SOURCE;
+	ret = media_entity_pads_init(&mipi_csi->sd.entity,
+				     CSI_PADS_NUM, mipi_csi->pads);
+
+	if (ret < 0) {
+		dev_err(dev, "Media Entity init failed\n");
+		goto entity_cleanup;
+	}
+
+	/* This allows to retrieve the platform device id by the host driver */
+	v4l2_set_subdevdata(&mipi_csi->sd, pdev);
+
+	/* .. and a pointer to the subdev. */
+	platform_set_drvdata(pdev, &mipi_csi->sd);
+
+	dw_mipi_csi_mask_irq_power_off(mipi_csi);
+	dev_info(dev, "DW MIPI CSI-2 Host registered successfully\n");
+	return 0;
+
+entity_cleanup:
+	media_entity_cleanup(&mipi_csi->sd.entity);
+end:
+	return ret;
+}
+
+/**
+ * @short Exit routine - Exit point of the driver
+ * @param[in] pdev pointer to the platform device structure
+ * @return 0 on success and a negative number on failure
+ * Refer to Linux errors.
+ */
+static int mipi_csi_remove(struct platform_device *pdev)
+{
+	struct v4l2_subdev *sd = platform_get_drvdata(pdev);
+	struct mipi_csi_dev *mipi_csi = sd_to_mipi_csi_dev(sd);
+
+	dev_dbg(&pdev->dev, "Removing MIPI CSI-2 module\n");
+	media_entity_cleanup(&mipi_csi->sd.entity);
+
+	return 0;
+}
+
+/**
+ * @short of_device_id structure
+ */
+static const struct of_device_id dw_mipi_csi_of_match[] = {
+	{
+	 .compatible = "snps,dw-mipi-csi"},
+	{ /* sentinel */ },
+};
+
+MODULE_DEVICE_TABLE(of, dw_mipi_csi_of_match);
+
+/**
+ * @short Platform driver structure
+ */
+static struct platform_driver __refdata dw_mipi_csi_pdrv = {
+	.remove = mipi_csi_remove,
+	.probe = mipi_csi_probe,
+	.driver = {
+		   .name = CSI_DEVICE_NAME,
+		   .owner = THIS_MODULE,
+		   .of_match_table = dw_mipi_csi_of_match,
+		   },
+};
+
+module_platform_driver(dw_mipi_csi_pdrv);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>");
+MODULE_DESCRIPTION("Synopsys DW MIPI CSI-2 Host driver");
diff --git a/drivers/media/platform/dwc/dw_mipi_csi.h b/drivers/media/platform/dwc/dw_mipi_csi.h
new file mode 100644
index 0000000..610a01f
--- /dev/null
+++ b/drivers/media/platform/dwc/dw_mipi_csi.h
@@ -0,0 +1,180 @@
+/*
+ * Copyright (C) 2016 Synopsys, Inc. All rights reserved.
+ *
+ * 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 DW_MIPI_CSI_H_
+#define DW_MIPI_CSI_H_
+
+#include <linux/delay.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_irq.h>
+#include <linux/of_graph.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/ratelimit.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/videodev2.h>
+#include <linux/wait.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-dv-timings.h>
+
+#include "plat_ipk_video.h"
+
+#define CSI_DEVICE_NAME	"dw-mipi-csi"
+
+/** @short DWC MIPI CSI-2 register addresses*/
+enum register_addresses {
+	R_CSI2_VERSION = 0x00,
+	R_CSI2_N_LANES = 0x04,
+	R_CSI2_CTRL_RESETN = 0x08,
+	R_CSI2_INTERRUPT = 0x0C,
+	R_CSI2_DATA_IDS_1 = 0x10,
+	R_CSI2_DATA_IDS_2 = 0x14,
+	R_CSI2_IPI_MODE = 0x80,
+	R_CSI2_IPI_VCID = 0x84,
+	R_CSI2_IPI_DATA_TYPE = 0x88,
+	R_CSI2_IPI_MEM_FLUSH = 0x8C,
+	R_CSI2_IPI_HSA_TIME = 0x90,
+	R_CSI2_IPI_HBP_TIME = 0x94,
+	R_CSI2_IPI_HSD_TIME = 0x98,
+	R_CSI2_IPI_HLINE_TIME = 0x9C,
+	R_CSI2_IPI_VSA_LINES = 0xB0,
+	R_CSI2_IPI_VBP_LINES = 0xB4,
+	R_CSI2_IPI_VFP_LINES = 0xB8,
+	R_CSI2_IPI_VACTIVE_LINES = 0xBC,
+	R_CSI2_INT_PHY_FATAL = 0xe0,
+	R_CSI2_MASK_INT_PHY_FATAL = 0xe4,
+	R_CSI2_FORCE_INT_PHY_FATAL = 0xe8,
+	R_CSI2_INT_PKT_FATAL = 0xf0,
+	R_CSI2_MASK_INT_PKT_FATAL = 0xf4,
+	R_CSI2_FORCE_INT_PKT_FATAL = 0xf8,
+	R_CSI2_INT_FRAME_FATAL = 0x100,
+	R_CSI2_MASK_INT_FRAME_FATAL = 0x104,
+	R_CSI2_FORCE_INT_FRAME_FATAL = 0x108,
+	R_CSI2_INT_PHY = 0x110,
+	R_CSI2_MASK_INT_PHY = 0x114,
+	R_CSI2_FORCE_INT_PHY = 0x118,
+	R_CSI2_INT_PKT = 0x120,
+	R_CSI2_MASK_INT_PKT = 0x124,
+	R_CSI2_FORCE_INT_PKT = 0x128,
+	R_CSI2_INT_LINE = 0x130,
+	R_CSI2_MASK_INT_LINE = 0x134,
+	R_CSI2_FORCE_INT_LINE = 0x138,
+	R_CSI2_INT_IPI = 0x140,
+	R_CSI2_MASK_INT_IPI = 0x144,
+	R_CSI2_FORCE_INT_IPI = 0x148
+};
+
+/** @short IPI Data Types */
+enum data_type {
+	CSI_2_YUV420_8 = 0x18,
+	CSI_2_YUV420_10 = 0x19,
+	CSI_2_YUV420_8_LEG = 0x1A,
+	CSI_2_YUV420_8_SHIFT = 0x1C,
+	CSI_2_YUV420_10_SHIFT = 0x1D,
+	CSI_2_YUV422_8 = 0x1E,
+	CSI_2_YUV422_10 = 0x1F,
+	CSI_2_RGB444 = 0x20,
+	CSI_2_RGB555 = 0x21,
+	CSI_2_RGB565 = 0x22,
+	CSI_2_RGB666 = 0x23,
+	CSI_2_RGB888 = 0x24,
+	CSI_2_RAW6 = 0x28,
+	CSI_2_RAW7 = 0x29,
+	CSI_2_RAW8 = 0x2A,
+	CSI_2_RAW10 = 0x2B,
+	CSI_2_RAW12 = 0x2C,
+	CSI_2_RAW14 = 0x2D,
+};
+
+/** @short Interrupt Masks */
+enum interrupt_type {
+	CSI2_INT_PHY_FATAL = 1 << 0,
+	CSI2_INT_PKT_FATAL = 1 << 1,
+	CSI2_INT_FRAME_FATAL = 1 << 2,
+	CSI2_INT_PHY = 1 << 16,
+	CSI2_INT_PKT = 1 << 17,
+	CSI2_INT_LINE = 1 << 18,
+	CSI2_INT_IPI = 1 << 19,
+
+};
+
+/** @short DWC MIPI CSI-2 output types*/
+enum output_type {
+	IPI_OUT = 0,
+	IDI_OUT = 1,
+	BOTH_OUT = 2
+};
+
+/** @short IPI output types*/
+enum ipi_output_type {
+	CAMERA_TIMING = 0,
+	AUTO_TIMING = 1
+};
+
+/**
+ * @short Format template
+ */
+struct mipi_fmt {
+	u32 code;
+	u8 depth;
+};
+
+struct csi_hw {
+
+	uint32_t num_lanes;
+	uint32_t output_type;
+
+	/*IPI Info */
+	uint32_t ipi_mode;
+	uint32_t ipi_color_mode;
+	uint32_t ipi_auto_flush;
+	uint32_t virtual_ch;
+
+	uint32_t hsa;
+	uint32_t hbp;
+	uint32_t hsd;
+	uint32_t htotal;
+
+	uint32_t vsa;
+	uint32_t vbp;
+	uint32_t vfp;
+	uint32_t vactive;
+};
+
+/**
+ * @short Structure to embed device driver information
+ */
+struct mipi_csi_dev {
+	struct v4l2_subdev sd;
+	struct video_device vdev;
+
+	struct mutex lock;
+	spinlock_t slock;
+	struct media_pad pads[CSI_PADS_NUM];
+	struct platform_device *pdev;
+	u8 index;
+
+	/** Store current format */
+	const struct mipi_fmt *fmt;
+	struct v4l2_mbus_framefmt format;
+
+	/** Device Tree Information */
+	void __iomem *base_address;
+	uint32_t ctrl_irq_number;
+
+	struct csi_hw hw;
+
+	struct phy *phy;
+};
+
+#endif				/* DW_MIPI_CSI */
diff --git a/drivers/media/platform/dwc/plat_ipk.c b/drivers/media/platform/dwc/plat_ipk.c
new file mode 100644
index 0000000..02dcf36
--- /dev/null
+++ b/drivers/media/platform/dwc/plat_ipk.c
@@ -0,0 +1,818 @@
+/**
+ * DWC MIPI CSI-2 Host IPK platform device driver
+ *
+ * Based on Omnivision OV7670 Camera Driver
+ * Copyright (C) 2011 - 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
+ *
+ * Copyright (C) 2016 Synopsys, Inc. All rights reserved.
+ * Author: Ramiro Oliveira <ramiro.oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include "plat_ipk.h"
+
+static int
+__plat_ipk_pipeline_s_format(struct plat_ipk_media_pipeline *ep,
+			     struct v4l2_subdev_format *fmt)
+{
+
+	struct plat_ipk_pipeline *p = to_plat_ipk_pipeline(ep);
+	static const u8 seq[IDX_MAX] = {IDX_SENSOR, IDX_CSI, IDX_VDEV};
+
+	fmt->which = V4L2_SUBDEV_FORMAT_ACTIVE;
+	v4l2_subdev_call(p->subdevs[seq[IDX_CSI]], pad, set_fmt, NULL, fmt);
+
+	return 0;
+}
+
+static void
+plat_ipk_pipeline_prepare(struct plat_ipk_pipeline *p, struct media_entity *me)
+{
+	struct v4l2_subdev *sd;
+	unsigned int i = 0;
+
+	for (i = 0; i < IDX_MAX; i++)
+		p->subdevs[i] = NULL;
+
+	while (1) {
+		struct media_pad *pad = NULL;
+
+		for (i = 0; i < me->num_pads; i++) {
+			struct media_pad *spad = &me->pads[i];
+
+			if (!(spad->flags & MEDIA_PAD_FL_SINK))
+				continue;
+
+			pad = media_entity_remote_pad(spad);
+			if (pad)
+				break;
+		}
+		if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
+			break;
+
+		sd = media_entity_to_v4l2_subdev(pad->entity);
+
+		switch (sd->grp_id) {
+		case GRP_ID_SENSOR:
+			p->subdevs[IDX_SENSOR] = sd;
+			break;
+		case GRP_ID_CSI:
+			p->subdevs[IDX_CSI] = sd;
+			break;
+		case GRP_ID_VIDEODEV:
+			p->subdevs[IDX_VDEV] = sd;
+			break;
+		default:
+			break;
+		}
+		me = &sd->entity;
+		if (me->num_pads == 1)
+			break;
+	}
+}
+
+static int __subdev_set_power(struct v4l2_subdev *sd, int on)
+{
+	int *use_count;
+	int ret;
+
+	if (sd == NULL) {
+		pr_err("null subdev\n");
+		return -ENXIO;
+	}
+	use_count = &sd->entity.use_count;
+	if (on && (*use_count)++ > 0)
+		return 0;
+	else if (!on && (*use_count == 0 || --(*use_count) > 0))
+		return 0;
+
+	ret = v4l2_subdev_call(sd, core, s_power, on);
+
+	return ret != -ENOIOCTLCMD ? ret : 0;
+}
+
+static int plat_ipk_pipeline_s_power(struct plat_ipk_pipeline *p, bool on)
+{
+	static const u8 seq[IDX_MAX] = {IDX_CSI, IDX_SENSOR, IDX_VDEV};
+	int i, ret = 0;
+
+	for (i = 0; i < IDX_MAX; i++) {
+		unsigned int idx = seq[i];
+
+		if (p->subdevs[idx] == NULL)
+			pr_info("No device registered on %d\n", idx);
+		else {
+			ret = __subdev_set_power(p->subdevs[idx], on);
+			if (ret < 0 && ret != -ENXIO)
+				goto error;
+		}
+	}
+	return 0;
+error:
+	for (; i >= 0; i--) {
+		unsigned int idx = seq[i];
+
+		__subdev_set_power(p->subdevs[idx], !on);
+	}
+	return ret;
+}
+
+static int
+__plat_ipk_pipeline_open(struct plat_ipk_media_pipeline *ep,
+			 struct media_entity *me, bool prepare)
+{
+	struct plat_ipk_pipeline *p = to_plat_ipk_pipeline(ep);
+	int ret;
+
+	if (WARN_ON(p == NULL || me == NULL))
+		return -EINVAL;
+
+	if (prepare)
+		plat_ipk_pipeline_prepare(p, me);
+
+	ret = plat_ipk_pipeline_s_power(p, 1);
+	if (!ret)
+		return 0;
+
+	return ret;
+}
+
+static int __plat_ipk_pipeline_close(struct plat_ipk_media_pipeline *ep)
+{
+	struct plat_ipk_pipeline *p = to_plat_ipk_pipeline(ep);
+	int ret;
+
+	ret = plat_ipk_pipeline_s_power(p, 0);
+
+	return ret == -ENXIO ? 0 : ret;
+}
+
+static int
+__plat_ipk_pipeline_s_stream(struct plat_ipk_media_pipeline *ep, bool on)
+{
+	static const u8 seq[IDX_MAX] = {IDX_SENSOR, IDX_CSI, IDX_VDEV};
+	struct plat_ipk_pipeline *p = to_plat_ipk_pipeline(ep);
+	int i, ret = 0;
+
+	for (i = 0; i < IDX_MAX; i++) {
+		unsigned int idx = seq[i];
+
+		if (p->subdevs[idx] == NULL)
+			pr_debug("No device registered on %d\n", idx);
+		else {
+			ret =
+			    v4l2_subdev_call(p->subdevs[idx], video, s_stream,
+					     on);
+
+			if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
+				goto error;
+		}
+	}
+	return 0;
+error:
+	for (; i >= 0; i--) {
+		unsigned int idx = seq[i];
+
+		v4l2_subdev_call(p->subdevs[idx], video, s_stream, !on);
+	}
+	return ret;
+}
+
+static const struct plat_ipk_media_pipeline_ops plat_ipk_pipeline_ops = {
+	.open = __plat_ipk_pipeline_open,
+	.close = __plat_ipk_pipeline_close,
+	.set_format = __plat_ipk_pipeline_s_format,
+	.set_stream = __plat_ipk_pipeline_s_stream,
+};
+
+static struct plat_ipk_media_pipeline *
+plat_ipk_pipeline_create(struct plat_ipk_dev *plat_ipk)
+{
+	struct plat_ipk_pipeline *p;
+
+	p = kzalloc(sizeof(*p), GFP_KERNEL);
+	if (!p)
+		return NULL;
+
+	list_add_tail(&p->list, &plat_ipk->pipelines);
+
+	p->ep.ops = &plat_ipk_pipeline_ops;
+	return &p->ep;
+}
+
+static void
+plat_ipk_pipelines_free(struct plat_ipk_dev *plat_ipk)
+{
+	while (!list_empty(&plat_ipk->pipelines)) {
+		struct plat_ipk_pipeline *p;
+
+		p = list_entry(plat_ipk->pipelines.next, typeof(*p), list);
+		list_del(&p->list);
+		kfree(p);
+	}
+}
+
+static int
+plat_ipk_parse_port_node(struct plat_ipk_dev *plat_ipk,
+			 struct device_node *port, unsigned int index)
+{
+	struct device_node *rem, *ep;
+	struct v4l2_of_endpoint endpoint;
+	struct plat_ipk_source_info *pd = &plat_ipk->sensor[index].pdata;
+
+	/* Assume here a port node can have only one endpoint node. */
+	ep = of_get_next_child(port, NULL);
+	if (!ep)
+		return 0;
+
+	v4l2_of_parse_endpoint(ep, &endpoint);
+	if (WARN_ON(endpoint.base.port == 0) || index >= PLAT_MAX_SENSORS)
+		return -EINVAL;
+
+	pd->mux_id = endpoint.base.port - 1;
+
+	rem = of_graph_get_remote_port_parent(ep);
+	of_node_put(ep);
+	if (rem == NULL) {
+		dev_info(plat_ipk->dev,
+			  "Remote device at %s not found\n", ep->full_name);
+		return 0;
+	}
+
+	if (WARN_ON(index >= ARRAY_SIZE(plat_ipk->sensor)))
+		return -EINVAL;
+
+	plat_ipk->sensor[index].asd.match_type = V4L2_ASYNC_MATCH_OF;
+	plat_ipk->sensor[index].asd.match.of.node = rem;
+	plat_ipk->async_subdevs[index] = &plat_ipk->sensor[index].asd;
+
+	plat_ipk->num_sensors++;
+
+	of_node_put(rem);
+	return 0;
+}
+
+
+static int plat_ipk_register_sensor_entities(struct plat_ipk_dev *plat_ipk)
+{
+	struct device_node *parent = plat_ipk->pdev->dev.of_node;
+	struct device_node *node;
+	int index = 0;
+	int ret;
+
+	plat_ipk->num_sensors = 0;
+
+	for_each_available_child_of_node(parent, node) {
+		struct device_node *port;
+
+		if (of_node_cmp(node->name, "csi2"))
+			continue;
+		port = of_get_next_child(node, NULL);
+		if (!port)
+			continue;
+
+		ret = plat_ipk_parse_port_node(plat_ipk, port, index);
+		if (ret < 0)
+			return ret;
+		index++;
+	}
+	return 0;
+}
+
+static int
+__of_get_port_id(struct device_node *np)
+{
+	u32 reg = 0;
+
+	np = of_get_child_by_name(np, "port");
+	if (!np)
+		return -EINVAL;
+	of_property_read_u32(np, "reg", &reg);
+
+	return reg - 1;
+}
+
+static int register_videodev_entity(struct plat_ipk_dev *plat_ipk,
+			 struct video_device_dev *vid_dev)
+{
+	struct v4l2_subdev *sd;
+	struct plat_ipk_media_pipeline *ep;
+	int ret;
+
+	sd = &vid_dev->subdev;
+	sd->grp_id = GRP_ID_VIDEODEV;
+
+	ep = plat_ipk_pipeline_create(plat_ipk);
+	if (!ep)
+		return -ENOMEM;
+
+	v4l2_set_subdev_hostdata(sd, ep);
+
+	ret = v4l2_device_register_subdev(&plat_ipk->v4l2_dev, sd);
+	if (!ret)
+		plat_ipk->vid_dev = vid_dev;
+	else
+		v4l2_err(&plat_ipk->v4l2_dev,
+			 "Failed to register Video Device\n");
+	return ret;
+}
+
+static int register_mipi_csi_entity(struct plat_ipk_dev *plat_ipk,
+			 struct platform_device *pdev, struct v4l2_subdev *sd)
+{
+	struct device_node *node = pdev->dev.of_node;
+	int id, ret;
+
+	id = node ? __of_get_port_id(node) : max(0, pdev->id);
+
+	if (WARN_ON(id < 0 || id >= CSI_MAX_ENTITIES))
+		return -ENOENT;
+
+	if (WARN_ON(plat_ipk->mipi_csi[id].sd))
+		return -EBUSY;
+
+	sd->grp_id = GRP_ID_CSI;
+	ret = v4l2_device_register_subdev(&plat_ipk->v4l2_dev, sd);
+
+	if (!ret)
+		plat_ipk->mipi_csi[id].sd = sd;
+	else
+		v4l2_err(&plat_ipk->v4l2_dev,
+			 "Failed to register MIPI-CSI.%d (%d)\n", id, ret);
+	return ret;
+}
+
+static int plat_ipk_register_platform_entity(struct plat_ipk_dev *plat_ipk,
+				struct platform_device *pdev, int plat_entity)
+{
+	struct device *dev = &pdev->dev;
+	int ret = -EPROBE_DEFER;
+	void *drvdata;
+
+	device_lock(dev);
+	if (!dev->driver || !try_module_get(dev->driver->owner))
+		goto dev_unlock;
+
+	drvdata = dev_get_drvdata(dev);
+
+	if (drvdata) {
+		switch (plat_entity) {
+		case IDX_VDEV:
+			ret = register_videodev_entity(plat_ipk, drvdata);
+			break;
+		case IDX_CSI:
+			ret = register_mipi_csi_entity(plat_ipk, pdev, drvdata);
+			break;
+		default:
+			ret = -ENODEV;
+		}
+	} else
+		dev_err(plat_ipk->dev, "%s no drvdata\n", dev_name(dev));
+	module_put(dev->driver->owner);
+dev_unlock:
+	device_unlock(dev);
+	if (ret == -EPROBE_DEFER)
+		dev_info(plat_ipk->dev,
+			 "deferring %s device registration\n", dev_name(dev));
+	else if (ret < 0)
+		dev_err(plat_ipk->dev,
+			"%s device registration failed (%d)\n", dev_name(dev),
+			ret);
+	return ret;
+}
+
+static int
+plat_ipk_register_platform_entities(struct plat_ipk_dev *plat_ipk,
+				    struct device_node *parent)
+{
+	struct device_node *node;
+	int ret = 0;
+
+	for_each_available_child_of_node(parent, node) {
+		struct platform_device *pdev;
+		int plat_entity = -1;
+
+		pdev = of_find_device_by_node(node);
+		if (!pdev)
+			continue;
+
+		if (!strcmp(node->name, VIDEODEV_OF_NODE_NAME))
+			plat_entity = IDX_VDEV;
+		else if (!strcmp(node->name, CSI_OF_NODE_NAME))
+			plat_entity = IDX_CSI;
+
+		if (plat_entity >= 0)
+			ret = plat_ipk_register_platform_entity(plat_ipk, pdev,
+								plat_entity);
+		put_device(&pdev->dev);
+		if (ret < 0)
+			break;
+	}
+
+	return ret;
+}
+
+static void
+plat_ipk_unregister_entities(struct plat_ipk_dev *plat_ipk)
+{
+	int i;
+	struct video_device_dev *dev = plat_ipk->vid_dev;
+
+	if (dev == NULL)
+		return;
+	v4l2_device_unregister_subdev(&dev->subdev);
+	dev->ve.pipe = NULL;
+	plat_ipk->vid_dev = NULL;
+
+	for (i = 0; i < CSI_MAX_ENTITIES; i++) {
+		if (plat_ipk->mipi_csi[i].sd == NULL)
+			continue;
+		v4l2_device_unregister_subdev(plat_ipk->mipi_csi[i].sd);
+		plat_ipk->mipi_csi[i].sd = NULL;
+	}
+
+	dev_info(plat_ipk->dev, "Unregistered all entities\n");
+}
+
+static int
+__plat_ipk_create_videodev_sink_links(struct plat_ipk_dev *plat_ipk,
+				      struct media_entity *source,
+				      int pad)
+{
+	struct media_entity *sink;
+	int ret = 0;
+
+	if (!plat_ipk->vid_dev)
+		return 0;
+
+	sink = &plat_ipk->vid_dev->subdev.entity;
+	ret = media_create_pad_link(source, pad, sink,
+				    CSI_PAD_SOURCE, MEDIA_LNK_FL_ENABLED);
+	if (ret)
+		return ret;
+
+	dev_dbg(plat_ipk->dev, "created link [%s] -> [%s]\n",
+		  source->name, sink->name);
+
+	return 0;
+}
+
+
+static int
+__plat_ipk_create_videodev_source_links(struct plat_ipk_dev *plat_ipk)
+{
+	struct media_entity *source, *sink;
+	int ret = 0;
+
+	struct video_device_dev *vid_dev = plat_ipk->vid_dev;
+
+	if (vid_dev == NULL)
+		return -ENODEV;
+
+	source = &vid_dev->subdev.entity;
+	sink = &vid_dev->ve.vdev.entity;
+
+	ret = media_create_pad_link(source, VIDEO_DEV_SD_PAD_SOURCE_DMA,
+				    sink, 0, MEDIA_LNK_FL_ENABLED);
+
+	dev_dbg(plat_ipk->dev, "created link [%s] -> [%s]\n",
+		  source->name, sink->name);
+	return ret;
+}
+
+static int
+plat_ipk_create_links(struct plat_ipk_dev *plat_ipk)
+{
+	struct v4l2_subdev *csi_sensor[CSI_MAX_ENTITIES] = { NULL };
+	struct v4l2_subdev *sensor, *csi;
+	struct media_entity *source;
+	struct plat_ipk_source_info *pdata;
+	int i, pad, ret = 0;
+
+	for (i = 0; i < plat_ipk->num_sensors; i++) {
+		if (plat_ipk->sensor[i].subdev == NULL)
+			continue;
+
+		sensor = plat_ipk->sensor[i].subdev;
+		pdata = v4l2_get_subdev_hostdata(sensor);
+		if (!pdata)
+			continue;
+
+		source = NULL;
+
+		csi = plat_ipk->mipi_csi[pdata->mux_id].sd;
+		if (WARN(csi == NULL, "MIPI-CSI interface specified but	dw-mipi-csi module is not loaded!\n"))
+			return -EINVAL;
+
+		pad = sensor->entity.num_pads - 1;
+		ret = media_create_pad_link(&sensor->entity, pad,
+					    &csi->entity, CSI_PAD_SINK,
+					    MEDIA_LNK_FL_IMMUTABLE |
+					    MEDIA_LNK_FL_ENABLED);
+
+		if (ret)
+			return ret;
+		dev_dbg(plat_ipk->dev, "created link [%s] -> [%s]\n",
+			  sensor->entity.name, csi->entity.name);
+
+		csi_sensor[pdata->mux_id] = sensor;
+	}
+
+	for (i = 0; i < CSI_MAX_ENTITIES; i++) {
+		if (plat_ipk->mipi_csi[i].sd == NULL) {
+			dev_info(plat_ipk->dev, "no link\n");
+			continue;
+		}
+
+		source = &plat_ipk->mipi_csi[i].sd->entity;
+		pad = VIDEO_DEV_SD_PAD_SINK_CSI;
+
+		ret = __plat_ipk_create_videodev_sink_links(plat_ipk, source,
+								pad);
+	}
+
+	ret = __plat_ipk_create_videodev_source_links(plat_ipk);
+	if (ret < 0)
+		return ret;
+
+	return ret;
+}
+
+static int __plat_ipk_modify_pipeline(struct media_entity *entity, bool enable)
+{
+	struct plat_ipk_video_entity *ve;
+	struct plat_ipk_pipeline *p;
+	struct video_device *vdev;
+	int ret;
+
+	vdev = media_entity_to_video_device(entity);
+
+	if (vdev->entity.use_count == 0)
+		return 0;
+
+	ve = vdev_to_plat_ipk_video_entity(vdev);
+	p = to_plat_ipk_pipeline(ve->pipe);
+
+	if (enable)
+		ret = __plat_ipk_pipeline_open(ve->pipe, entity, true);
+	else
+		ret = __plat_ipk_pipeline_close(ve->pipe);
+
+	if (ret == 0 && !enable)
+		memset(p->subdevs, 0, sizeof(p->subdevs));
+
+	return ret;
+}
+
+
+static int
+__plat_ipk_modify_pipelines(struct media_entity *entity, bool enable,
+			    struct media_entity_graph *graph)
+{
+	struct media_entity *entity_err = entity;
+	int ret;
+
+	media_entity_graph_walk_start(graph, entity);
+
+	while ((entity = media_entity_graph_walk_next(graph))) {
+		if (!is_media_entity_v4l2_video_device(entity))
+			continue;
+
+		ret = __plat_ipk_modify_pipeline(entity, enable);
+
+		if (ret < 0)
+			goto err;
+	}
+
+	return 0;
+
+err:
+	media_entity_graph_walk_start(graph, entity_err);
+
+	while ((entity_err = media_entity_graph_walk_next(graph))) {
+		if (!is_media_entity_v4l2_video_device(entity_err))
+			continue;
+
+		__plat_ipk_modify_pipeline(entity_err, !enable);
+
+		if (entity_err == entity)
+			break;
+	}
+
+	return ret;
+}
+
+static int
+plat_ipk_link_notify(struct media_link *link, unsigned int flags,
+		     unsigned int notification)
+{
+	struct media_entity_graph *graph =
+	    &container_of(link->graph_obj.mdev, struct plat_ipk_dev,
+			  media_dev)->link_setup_graph;
+	struct media_entity *sink = link->sink->entity;
+	int ret = 0;
+
+	if (notification == MEDIA_DEV_NOTIFY_PRE_LINK_CH) {
+		ret = media_entity_graph_walk_init(graph, link->graph_obj.mdev);
+		if (ret)
+			return ret;
+		if (!(flags & MEDIA_LNK_FL_ENABLED))
+			ret = __plat_ipk_modify_pipelines(sink, false, graph);
+
+	} else if (notification == MEDIA_DEV_NOTIFY_POST_LINK_CH) {
+		if (link->flags & MEDIA_LNK_FL_ENABLED)
+			ret = __plat_ipk_modify_pipelines(sink, true, graph);
+		media_entity_graph_walk_cleanup(graph);
+	}
+
+	return ret ? -EPIPE : 0;
+}
+
+static const struct media_device_ops plat_ipk_media_ops = {
+	.link_notify = plat_ipk_link_notify,
+};
+
+
+static int
+subdev_notifier_bound(struct v4l2_async_notifier *notifier,
+		      struct v4l2_subdev *subdev, struct v4l2_async_subdev *asd)
+{
+	struct plat_ipk_dev *plat_ipk = notifier_to_plat_ipk(notifier);
+	struct plat_ipk_sensor_info *si = NULL;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(plat_ipk->sensor); i++)
+		if (plat_ipk->sensor[i].asd.match.of.node ==
+		    subdev->dev->of_node)
+			si = &plat_ipk->sensor[i];
+
+	if (si == NULL)
+		return -EINVAL;
+
+	v4l2_set_subdev_hostdata(subdev, &si->pdata);
+
+	subdev->grp_id = GRP_ID_SENSOR;
+
+	si->subdev = subdev;
+
+	dev_dbg(&plat_ipk->pdev->dev, "Registered sensor subdevice: %s (%d)\n",
+		  subdev->name, plat_ipk->num_sensors);
+
+	plat_ipk->num_sensors++;
+
+	return 0;
+}
+
+static int
+subdev_notifier_complete(struct v4l2_async_notifier *notifier)
+{
+	struct plat_ipk_dev *plat_ipk = notifier_to_plat_ipk(notifier);
+	int ret;
+
+	mutex_lock(&plat_ipk->media_dev.graph_mutex);
+
+	ret = plat_ipk_create_links(plat_ipk);
+	if (ret < 0)
+		goto unlock;
+
+	ret = v4l2_device_register_subdev_nodes(&plat_ipk->v4l2_dev);
+unlock:
+	mutex_unlock(&plat_ipk->media_dev.graph_mutex);
+	if (ret < 0)
+		return ret;
+
+	return media_device_register(&plat_ipk->media_dev);
+}
+
+static int plat_ipk_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct v4l2_device *v4l2_dev;
+	struct plat_ipk_dev *plat_ipk;
+	int ret;
+
+	dev_dbg(dev, "Installing DW MIPI CSI-2 IPK Platform module\n");
+
+	plat_ipk = devm_kzalloc(dev, sizeof(*plat_ipk), GFP_KERNEL);
+	if (!plat_ipk)
+		return -ENOMEM;
+
+	spin_lock_init(&plat_ipk->slock);
+	INIT_LIST_HEAD(&plat_ipk->pipelines);
+	plat_ipk->pdev = pdev;
+
+	strlcpy(plat_ipk->media_dev.model, "SNPS IPK Platform",
+		sizeof(plat_ipk->media_dev.model));
+	plat_ipk->media_dev.ops = &plat_ipk_media_ops;
+	plat_ipk->media_dev.dev = dev;
+
+	v4l2_dev = &plat_ipk->v4l2_dev;
+	v4l2_dev->mdev = &plat_ipk->media_dev;
+	strlcpy(v4l2_dev->name, "plat-ipk", sizeof(v4l2_dev->name));
+
+	media_device_init(&plat_ipk->media_dev);
+
+	ret = v4l2_device_register(dev, &plat_ipk->v4l2_dev);
+	if (ret < 0) {
+		v4l2_err(v4l2_dev, "Failed to register v4l2_device: %d\n", ret);
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, plat_ipk);
+
+	ret = plat_ipk_register_platform_entities(plat_ipk, dev->of_node);
+	if (ret)
+		goto err_m_ent;
+
+	ret = plat_ipk_register_sensor_entities(plat_ipk);
+	if (ret)
+		goto err_m_ent;
+
+	if (plat_ipk->num_sensors > 0) {
+		plat_ipk->subdev_notifier.subdevs = plat_ipk->async_subdevs;
+		plat_ipk->subdev_notifier.num_subdevs = plat_ipk->num_sensors;
+		plat_ipk->subdev_notifier.bound = subdev_notifier_bound;
+		plat_ipk->subdev_notifier.complete = subdev_notifier_complete;
+		plat_ipk->num_sensors = 0;
+
+		ret = v4l2_async_notifier_register(&plat_ipk->v4l2_dev,
+						   &plat_ipk->subdev_notifier);
+		if (ret)
+			goto err_m_ent;
+	}
+
+	return 0;
+
+err_m_ent:
+	plat_ipk_unregister_entities(plat_ipk);
+	media_device_unregister(&plat_ipk->media_dev);
+	media_device_cleanup(&plat_ipk->media_dev);
+	v4l2_device_unregister(&plat_ipk->v4l2_dev);
+	return ret;
+}
+
+static int plat_ipk_remove(struct platform_device *pdev)
+{
+	struct plat_ipk_dev *dev = platform_get_drvdata(pdev);
+
+	v4l2_async_notifier_unregister(&dev->subdev_notifier);
+
+	v4l2_device_unregister(&dev->v4l2_dev);
+	plat_ipk_unregister_entities(dev);
+	plat_ipk_pipelines_free(dev);
+	media_device_unregister(&dev->media_dev);
+	media_device_cleanup(&dev->media_dev);
+
+	dev_info(&pdev->dev, "Driver removed\n");
+
+	return 0;
+}
+
+/**
+ * @short of_device_id structure
+ */
+static const struct of_device_id plat_ipk_of_match[] = {
+	{.compatible = "snps,plat-ipk"},
+	{}
+};
+
+MODULE_DEVICE_TABLE(of, plat_ipk_of_match);
+
+/**
+ * @short Platform driver structure
+ */
+static struct platform_driver plat_ipk_pdrv = {
+	.remove = plat_ipk_remove,
+	.probe = plat_ipk_probe,
+	.driver = {
+		   .name = "snps,plat-ipk",
+		   .owner = THIS_MODULE,
+		   .of_match_table = plat_ipk_of_match,
+		   },
+};
+
+static int __init
+plat_ipk_init(void)
+{
+	request_module("dw-mipi-csi");
+
+	return platform_driver_register(&plat_ipk_pdrv);
+}
+
+static void __exit
+plat_ipk_exit(void)
+{
+	platform_driver_unregister(&plat_ipk_pdrv);
+}
+
+module_init(plat_ipk_init);
+module_exit(plat_ipk_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>");
+MODULE_DESCRIPTION("Platform driver for MIPI CSI-2 Host IPK");
diff --git a/drivers/media/platform/dwc/plat_ipk.h b/drivers/media/platform/dwc/plat_ipk.h
new file mode 100644
index 0000000..ff2f98b
--- /dev/null
+++ b/drivers/media/platform/dwc/plat_ipk.h
@@ -0,0 +1,101 @@
+/*
+ * Copyright (C) 2016 Synopsys, Inc. All rights reserved.
+ *
+ * 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 PLAT_IPK_H_
+#define PLAT_IPK_H_
+
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/videodev2.h>
+#include <media/media-entity.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-of.h>
+#include <media/v4l2-subdev.h>
+
+#include "dw_mipi_csi.h"
+#include "plat_ipk_video.h"
+#include "video_device.h"
+
+#define VIDEODEV_OF_NODE_NAME	"video-device"
+#define CSI_OF_NODE_NAME	"csi2"
+
+enum plat_ipk_subdev_index {
+	IDX_SENSOR,
+	IDX_CSI,
+	IDX_VDEV,
+	IDX_MAX,
+};
+
+struct plat_ipk_sensor_info {
+	struct plat_ipk_source_info pdata;
+	struct v4l2_async_subdev asd;
+	struct v4l2_subdev *subdev;
+	struct mipi_csi_dev *host;
+};
+
+struct plat_ipk_pipeline {
+	struct plat_ipk_media_pipeline ep;
+	struct list_head list;
+	struct media_entity *vdev_entity;
+	struct v4l2_subdev *subdevs[IDX_MAX];
+};
+
+#define to_plat_ipk_pipeline(_ep)\
+	 container_of(_ep, struct plat_ipk_pipeline, ep)
+
+struct mipi_csi_info {
+	struct v4l2_subdev *sd;
+	int id;
+};
+
+/**
+ * @short Structure to embed device driver information
+ */
+struct plat_ipk_dev {
+	struct mipi_csi_info		mipi_csi[CSI_MAX_ENTITIES];
+	struct video_device_dev		*vid_dev;
+	struct device			*dev;
+	struct media_device		media_dev;
+	struct v4l2_device		v4l2_dev;
+	struct platform_device		*pdev;
+	struct plat_ipk_sensor_info	sensor[PLAT_MAX_SENSORS];
+	struct v4l2_async_notifier	subdev_notifier;
+	struct v4l2_async_subdev	*async_subdevs[PLAT_MAX_SENSORS];
+	spinlock_t			slock;
+	struct list_head		pipelines;
+	int				num_sensors;
+	struct media_entity_graph	link_setup_graph;
+};
+
+static inline struct plat_ipk_dev *
+entity_to_plat_ipk_mdev(struct media_entity *me)
+{
+	return me->graph_obj.mdev == NULL ? NULL :
+	    container_of(me->graph_obj.mdev, struct plat_ipk_dev, media_dev);
+}
+
+static inline struct plat_ipk_dev *
+notifier_to_plat_ipk(struct v4l2_async_notifier *n)
+{
+	return container_of(n, struct plat_ipk_dev, subdev_notifier);
+}
+
+static inline void
+plat_ipk_graph_unlock(struct plat_ipk_video_entity *ve)
+{
+	mutex_unlock(&ve->vdev.entity.graph_obj.mdev->graph_mutex);
+}
+
+#endif				/* PLAT_IPK_H_ */
diff --git a/drivers/media/platform/dwc/plat_ipk_video.h b/drivers/media/platform/dwc/plat_ipk_video.h
new file mode 100644
index 0000000..9956ead
--- /dev/null
+++ b/drivers/media/platform/dwc/plat_ipk_video.h
@@ -0,0 +1,97 @@
+/*
+ * Copyright (C) 2016 Synopsys, Inc. All rights reserved.
+ *
+ * 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 PLAT_IPK_INCLUDES_H_
+#define PLAT_IPK_INCLUDES_H_
+
+#include <media/media-entity.h>
+#include <media/v4l2-dev.h>
+#include <media/v4l2-mediabus.h>
+#include <media/v4l2-subdev.h>
+
+/*
+ * The subdevices' group IDs.
+ */
+
+#define MAX_WIDTH	3280
+#define MAX_HEIGHT	1852
+
+#define MIN_WIDTH	640
+#define MIN_HEIGHT	480
+
+#define GRP_ID_SENSOR		(10)
+#define GRP_ID_CSI		(20)
+#define GRP_ID_VIDEODEV		(30)
+
+#define CSI_MAX_ENTITIES	1
+#define PLAT_MAX_SENSORS	1
+
+enum video_dev_pads {
+	VIDEO_DEV_SD_PAD_SINK_CSI = 0,
+	VIDEO_DEV_SD_PAD_SOURCE_DMA = 1,
+	VIDEO_DEV_SD_PADS_NUM = 2,
+};
+
+enum mipi_csi_pads {
+	CSI_PAD_SINK = 0,
+	CSI_PAD_SOURCE = 1,
+	CSI_PADS_NUM = 2,
+};
+
+struct plat_ipk_source_info {
+	u16 flags;
+	u16 mux_id;
+};
+
+struct plat_ipk_fmt {
+	char *name;
+	u32 mbus_code;
+	u32 fourcc;
+	u8 depth;
+};
+
+struct plat_ipk_media_pipeline;
+
+/*
+ * Media pipeline operations to be called from within a video node,  i.e. the
+ * last entity within the pipeline. Implemented by related media device driver.
+ */
+struct plat_ipk_media_pipeline_ops {
+	int (*prepare)(struct plat_ipk_media_pipeline *p,
+			struct media_entity *me);
+	int (*unprepare)(struct plat_ipk_media_pipeline *p);
+	int (*open)(struct plat_ipk_media_pipeline *p,
+			struct media_entity *me, bool resume);
+	int (*close)(struct plat_ipk_media_pipeline *p);
+	int (*set_stream)(struct plat_ipk_media_pipeline *p, bool state);
+	int (*set_format)(struct plat_ipk_media_pipeline *p,
+			struct v4l2_subdev_format *fmt);
+};
+
+struct plat_ipk_video_entity {
+	struct video_device vdev;
+	struct plat_ipk_media_pipeline *pipe;
+};
+
+struct plat_ipk_media_pipeline {
+	struct media_pipeline mp;
+	const struct plat_ipk_media_pipeline_ops *ops;
+};
+
+static inline struct plat_ipk_video_entity *
+vdev_to_plat_ipk_video_entity(struct video_device *vdev)
+{
+	return container_of(vdev, struct plat_ipk_video_entity, vdev);
+}
+
+#define plat_ipk_pipeline_call(ent, op, args...)\
+	(!(ent) ? -ENOENT : (((ent)->pipe->ops && (ent)->pipe->ops->op) ? \
+	(ent)->pipe->ops->op(((ent)->pipe), ##args) : -ENOIOCTLCMD))	  \
+
+
+#endif				/* PLAT_IPK_INCLUDES_H_ */
diff --git a/drivers/media/platform/dwc/video_device.c b/drivers/media/platform/dwc/video_device.c
new file mode 100644
index 0000000..8e7033c
--- /dev/null
+++ b/drivers/media/platform/dwc/video_device.c
@@ -0,0 +1,707 @@
+/*
+ * DWC MIPI CSI-2 Host IPK video device device driver
+ *
+ * Copyright (C) 2016 Synopsys, Inc. All rights reserved.
+ * Author: Ramiro Oliveira <ramiro.oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include "video_device.h"
+
+static const struct plat_ipk_fmt vid_dev_formats[] = {
+	{
+		.name = "BGR888",
+		.fourcc = V4L2_PIX_FMT_BGR24,
+		.depth = 24,
+		.mbus_code = MEDIA_BUS_FMT_RGB888_2X12_LE,
+	}, {
+		.name = "RGB565",
+		.fourcc = V4L2_PIX_FMT_RGB565,
+		.depth = 16,
+		.mbus_code = MEDIA_BUS_FMT_RGB565_2X8_BE,
+	},
+};
+
+static const struct plat_ipk_fmt *
+vid_dev_find_format(struct v4l2_format *f, int index)
+{
+	const struct plat_ipk_fmt *fmt = NULL;
+	unsigned int i;
+
+	if (index >= (int) ARRAY_SIZE(vid_dev_formats))
+		return NULL;
+
+	for (i = 0; i < ARRAY_SIZE(vid_dev_formats); ++i) {
+		fmt = &vid_dev_formats[i];
+		if (fmt->fourcc == f->fmt.pix.pixelformat)
+			return fmt;
+	}
+	return NULL;
+}
+
+/*
+ * Video node ioctl operations
+ */
+static int
+vidioc_querycap(struct file *file, void *priv, struct v4l2_capability *cap)
+{
+	struct video_device_dev *vid_dev = video_drvdata(file);
+
+	strlcpy(cap->driver, VIDEO_DEVICE_NAME, sizeof(cap->driver));
+	strlcpy(cap->card, VIDEO_DEVICE_NAME, sizeof(cap->card));
+	snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
+		 dev_name(&vid_dev->pdev->dev));
+
+	cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+	cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
+	return 0;
+}
+
+static int
+vidioc_enum_fmt_vid_cap(struct file *file, void *priv, struct v4l2_fmtdesc *f)
+{
+	const struct plat_ipk_fmt *p_fmt;
+
+	if (f->index >= ARRAY_SIZE(vid_dev_formats))
+		return -EINVAL;
+
+	p_fmt = &vid_dev_formats[f->index];
+
+	strlcpy(f->description, p_fmt->name, sizeof(f->description));
+	f->pixelformat = p_fmt->fourcc;
+
+	return 0;
+}
+
+static int vidioc_g_fmt_vid_cap(struct file *file, void *priv,
+					struct v4l2_format *f)
+{
+	struct video_device_dev *dev = video_drvdata(file);
+
+	memcpy(&f->fmt.pix, &dev->format.fmt.pix,
+	       sizeof(struct v4l2_pix_format));
+
+	return 0;
+}
+
+static int
+vidioc_try_fmt_vid_cap(struct file *file, void *priv, struct v4l2_format *f)
+{
+	const struct plat_ipk_fmt *fmt;
+
+	fmt = vid_dev_find_format(f, -1);
+	if (!fmt) {
+		f->fmt.pix.pixelformat = V4L2_PIX_FMT_RGB565;
+		fmt = vid_dev_find_format(f, -1);
+	}
+
+	f->fmt.pix.field = V4L2_FIELD_NONE;
+	v4l_bound_align_image(&f->fmt.pix.width, 48, MAX_WIDTH, 2,
+			      &f->fmt.pix.height, 32, MAX_HEIGHT, 0, 0);
+
+	f->fmt.pix.bytesperline = (f->fmt.pix.width * fmt->depth) >> 3;
+	f->fmt.pix.sizeimage = f->fmt.pix.height * f->fmt.pix.bytesperline;
+	f->fmt.pix.colorspace = V4L2_COLORSPACE_SRGB;
+	return 0;
+}
+
+static int vidioc_s_fmt_vid_cap(struct file *file, void *priv,
+					struct v4l2_format *f)
+{
+	struct video_device_dev *dev = video_drvdata(file);
+	int ret;
+	struct v4l2_subdev_format fmt;
+	struct v4l2_pix_format *dev_fmt_pix = &dev->format.fmt.pix;
+
+	if (vb2_is_busy(&dev->vb_queue))
+		return -EBUSY;
+
+	ret = vidioc_try_fmt_vid_cap(file, dev, f);
+	if (ret)
+		return ret;
+
+	dev->fmt = vid_dev_find_format(f, -1);
+	dev_fmt_pix->pixelformat = f->fmt.pix.pixelformat;
+	dev_fmt_pix->width = f->fmt.pix.width;
+	dev_fmt_pix->height  = f->fmt.pix.height;
+	dev_fmt_pix->bytesperline = dev_fmt_pix->width * (dev->fmt->depth / 8);
+	dev_fmt_pix->sizeimage =
+			dev_fmt_pix->height * dev_fmt_pix->bytesperline;
+
+	fmt.format.colorspace = V4L2_COLORSPACE_SRGB;
+	fmt.format.code = dev->fmt->mbus_code;
+
+	fmt.format.width = dev_fmt_pix->width;
+	fmt.format.height = dev_fmt_pix->height;
+
+	ret = plat_ipk_pipeline_call(&dev->ve, set_format, &fmt);
+
+	return 0;
+}
+
+static int vidioc_enum_framesizes(struct file *file, void *fh,
+		       struct v4l2_frmsizeenum *fsize)
+{
+	static const struct v4l2_frmsize_stepwise sizes = {
+		48, MAX_WIDTH, 4,
+		32, MAX_HEIGHT, 1
+	};
+	int i;
+
+	if (fsize->index)
+		return -EINVAL;
+	for (i = 0; i < ARRAY_SIZE(vid_dev_formats); i++)
+		if (vid_dev_formats[i].fourcc == fsize->pixel_format)
+			break;
+	if (i == ARRAY_SIZE(vid_dev_formats))
+		return -EINVAL;
+	fsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
+	fsize->stepwise = sizes;
+	return 0;
+}
+
+static int vidioc_enum_input(struct file *file, void *priv,
+			struct v4l2_input *input)
+{
+	if (input->index != 0)
+		return -EINVAL;
+
+	input->type = V4L2_INPUT_TYPE_CAMERA;
+	input->std = V4L2_STD_ALL;	/* Not sure what should go here */
+	strcpy(input->name, "Camera");
+	return 0;
+}
+
+static int vidioc_g_input(struct file *file, void *priv, unsigned int *i)
+{
+	*i = 0;
+	return 0;
+}
+
+static int vidioc_s_input(struct file *file, void *priv, unsigned int i)
+{
+	if (i != 0)
+		return -EINVAL;
+	return 0;
+}
+
+static int
+vid_dev_streamon(struct file *file, void *priv, enum v4l2_buf_type type)
+{
+	struct video_device_dev *vid_dev = video_drvdata(file);
+	struct media_entity *entity = &vid_dev->ve.vdev.entity;
+	int ret;
+
+	ret = media_entity_pipeline_start(entity, &vid_dev->ve.pipe->mp);
+	if (ret < 0)
+		return ret;
+
+	vb2_ioctl_streamon(file, priv, type);
+	if (!ret)
+		return ret;
+
+	media_entity_pipeline_stop(entity);
+	return 0;
+}
+
+static int
+vid_dev_streamoff(struct file *file, void *priv, enum v4l2_buf_type type)
+{
+	struct video_device_dev *vid_dev = video_drvdata(file);
+	int ret;
+
+	ret = vb2_ioctl_streamoff(file, priv, type);
+	if (ret < 0)
+		return ret;
+
+	media_entity_pipeline_stop(&vid_dev->ve.vdev.entity);
+	return 0;
+}
+
+static const struct v4l2_ioctl_ops vid_dev_ioctl_ops = {
+	.vidioc_querycap = vidioc_querycap,
+	.vidioc_enum_fmt_vid_cap = vidioc_enum_fmt_vid_cap,
+	.vidioc_g_fmt_vid_cap = vidioc_g_fmt_vid_cap,
+	.vidioc_s_fmt_vid_cap = vidioc_s_fmt_vid_cap,
+	.vidioc_enum_framesizes = vidioc_enum_framesizes,
+	.vidioc_enum_input = vidioc_enum_input,
+	.vidioc_g_input = vidioc_g_input,
+	.vidioc_s_input = vidioc_s_input,
+
+	.vidioc_reqbufs = vb2_ioctl_reqbufs,
+	.vidioc_create_bufs = vb2_ioctl_create_bufs,
+	.vidioc_prepare_buf = vb2_ioctl_prepare_buf,
+	.vidioc_querybuf = vb2_ioctl_querybuf,
+	.vidioc_qbuf = vb2_ioctl_qbuf,
+	.vidioc_dqbuf = vb2_ioctl_dqbuf,
+	.vidioc_streamon = vid_dev_streamon,
+	.vidioc_streamoff = vid_dev_streamoff,
+};
+
+static int
+vid_dev_open(struct file *file)
+{
+	struct video_device_dev *vid_dev = video_drvdata(file);
+	struct media_entity *me = &vid_dev->ve.vdev.entity;
+	int ret;
+
+	mutex_lock(&vid_dev->lock);
+
+	ret = v4l2_fh_open(file);
+	if (ret < 0)
+		goto unlock;
+
+	if (!v4l2_fh_is_singular_file(file))
+		goto unlock;
+
+	mutex_lock(&me->graph_obj.mdev->graph_mutex);
+
+	ret = plat_ipk_pipeline_call(&vid_dev->ve, open, me, true);
+	if (ret == 0)
+		me->use_count++;
+
+	mutex_unlock(&me->graph_obj.mdev->graph_mutex);
+
+	if (!ret)
+		goto unlock;
+
+	v4l2_fh_release(file);
+unlock:
+	mutex_unlock(&vid_dev->lock);
+	return ret;
+}
+
+static int
+vid_dev_release(struct file *file)
+{
+	struct video_device_dev *vid_dev = video_drvdata(file);
+	struct media_entity *entity = &vid_dev->ve.vdev.entity;
+
+	mutex_lock(&vid_dev->lock);
+
+	if (v4l2_fh_is_singular_file(file)) {
+		plat_ipk_pipeline_call(&vid_dev->ve, close);
+		mutex_lock(&entity->graph_obj.mdev->graph_mutex);
+		entity->use_count--;
+		mutex_unlock(&entity->graph_obj.mdev->graph_mutex);
+	}
+
+	_vb2_fop_release(file, NULL);
+
+	mutex_unlock(&vid_dev->lock);
+	return 0;
+}
+
+static const struct v4l2_file_operations vid_dev_fops = {
+	.owner = THIS_MODULE,
+	.open = vid_dev_open,
+	.release = vid_dev_release,
+	.write = vb2_fop_write,
+	.read = vb2_fop_read,
+	.poll = vb2_fop_poll,
+	.unlocked_ioctl = video_ioctl2,
+	.mmap = vb2_fop_mmap,
+};
+
+/*
+ * VideoBuffer2 operations
+ */
+
+static void fill_buffer(struct video_device_dev *dev, struct rx_buffer *buf,
+			int buf_num, unsigned long flags)
+{
+	int size = 0;
+	void *vbuf = NULL;
+
+	if (&buf->vb == NULL)
+		return;
+
+	size = vb2_plane_size(&buf->vb.vb2_buf, 0);
+	vbuf = vb2_plane_vaddr(&buf->vb.vb2_buf, 0);
+
+	if (vbuf) {
+		spin_unlock_irqrestore(&dev->slock, flags);
+
+		memcpy(vbuf, dev->dma_buf[buf_num].cpu_addr, size);
+
+		spin_lock_irqsave(&dev->slock, flags);
+
+		buf->vb.field = dev->format.fmt.pix.field;
+		buf->vb.sequence++;
+		buf->vb.vb2_buf.timestamp = ktime_get_ns();
+	}
+	vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_DONE);
+}
+
+static void buffer_copy_process(void *param)
+{
+	struct video_device_dev *dev = (struct video_device_dev *) param;
+	unsigned long flags;
+	struct dmaqueue *dma_q = &dev->vidq;
+	struct rx_buffer *buf = NULL;
+
+	spin_lock_irqsave(&dev->slock, flags);
+
+	if (!list_empty(&dma_q->active)) {
+		buf = list_entry(dma_q->active.next, struct rx_buffer, list);
+		list_del(&buf->list);
+		fill_buffer(dev, buf, dev->last_idx, flags);
+	}
+
+	spin_unlock_irqrestore(&dev->slock, flags);
+}
+
+static inline struct rx_buffer *to_rx_buffer(struct vb2_v4l2_buffer *vb2)
+{
+	return container_of(vb2, struct rx_buffer, vb);
+}
+
+static int queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,
+			unsigned int *nplanes, unsigned int sizes[],
+			struct device *alloc_devs[])
+{
+	struct video_device_dev *dev = vb2_get_drv_priv(vq);
+	unsigned long size = 0;
+	int i;
+
+	size = dev->format.fmt.pix.sizeimage;
+	if (size == 0)
+		return -EINVAL;
+
+	*nbuffers = N_BUFFERS;
+
+	for (i = 0; i < N_BUFFERS; i++) {
+		dev->dma_buf[i].cpu_addr = dma_alloc_coherent(&dev->pdev->dev,
+						dev->format.fmt.pix.sizeimage,
+						&dev->dma_buf[i].dma_addr,
+						GFP_KERNEL);
+	}
+
+	*nplanes = 1;
+	sizes[0] = size;
+
+	return 0;
+}
+
+static int buffer_prepare(struct vb2_buffer *vb)
+{
+	struct rx_buffer *buf = NULL;
+	struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+	int size = 0;
+
+	if (vb == NULL) {
+		pr_warn("%s:vb2_buffer is null\n", FUNC_NAME);
+		return 0;
+	}
+
+	buf = to_rx_buffer(vbuf);
+
+	size = vb2_plane_size(&buf->vb.vb2_buf, 0);
+	vb2_set_plane_payload(&buf->vb.vb2_buf, 0, size);
+
+	INIT_LIST_HEAD(&buf->list);
+	return 0;
+}
+
+static void buffer_queue(struct vb2_buffer *vb)
+{
+	struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+	struct video_device_dev *dev = NULL;
+	struct rx_buffer *buf = NULL;
+	struct dmaqueue *vidq = NULL;
+	struct dma_async_tx_descriptor *desc;
+	u32 flags;
+
+	if (vb == NULL) {
+		pr_warn("%s:vb2_buffer is null\n", FUNC_NAME);
+		return;
+	}
+
+	dev = vb2_get_drv_priv(vb->vb2_queue);
+	buf = to_rx_buffer(vbuf);
+	vidq = &dev->vidq;
+
+	flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK;
+	dev->xt.dir = DMA_DEV_TO_MEM;
+	dev->xt.src_sgl = false;
+	dev->xt.dst_inc = false;
+	dev->xt.dst_sgl = true;
+	dev->xt.dst_start = dev->dma_buf[dev->idx].dma_addr;
+
+	dev->last_idx = dev->idx;
+	dev->idx++;
+	if (dev->idx >= N_BUFFERS)
+		dev->idx = 0;
+
+	dev->xt.frame_size = 1;
+	dev->sgl[0].size = dev->format.fmt.pix.bytesperline;
+	dev->sgl[0].icg = 0;
+	dev->xt.numf = dev->format.fmt.pix.height;
+
+	desc = dmaengine_prep_interleaved_dma(dev->dma, &dev->xt, flags);
+	if (!desc) {
+		pr_err("Failed to prepare DMA transfer\n");
+		vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
+		return;
+	}
+
+	desc->callback = buffer_copy_process;
+	desc->callback_param = dev;
+
+	spin_lock(&dev->slock);
+	list_add_tail(&buf->list, &vidq->active);
+	spin_unlock(&dev->slock);
+
+	dmaengine_submit(desc);
+
+	if (vb2_is_streaming(&dev->vb_queue))
+		dma_async_issue_pending(dev->dma);
+}
+
+static int start_streaming(struct vb2_queue *vq, unsigned int count)
+{
+	struct video_device_dev *dev = vb2_get_drv_priv(vq);
+
+	dma_async_issue_pending(dev->dma);
+
+	return 0;
+}
+
+static void stop_streaming(struct vb2_queue *vq)
+{
+	struct video_device_dev *dev = vb2_get_drv_priv(vq);
+	struct dmaqueue *dma_q = &dev->vidq;
+
+	/* Stop and reset the DMA engine. */
+	dmaengine_terminate_all(dev->dma);
+
+	while (!list_empty(&dma_q->active)) {
+		struct rx_buffer *buf;
+
+		buf = list_entry(dma_q->active.next, struct rx_buffer, list);
+		if (buf) {
+			list_del(&buf->list);
+			vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
+		}
+	}
+	list_del_init(&dev->vidq.active);
+}
+
+static const struct vb2_ops vb2_video_qops = {
+	.queue_setup = queue_setup,
+	.buf_prepare = buffer_prepare,
+	.buf_queue = buffer_queue,
+	.start_streaming = start_streaming,
+	.stop_streaming = stop_streaming,
+	.wait_prepare = vb2_ops_wait_prepare,
+	.wait_finish = vb2_ops_wait_finish,
+};
+
+static int vid_dev_subdev_s_power(struct v4l2_subdev *sd, int on)
+{
+	return 0;
+}
+
+static int vid_dev_subdev_registered(struct v4l2_subdev *sd)
+{
+	struct video_device_dev *vid_dev = v4l2_get_subdevdata(sd);
+	struct vb2_queue *q = &vid_dev->vb_queue;
+	struct video_device *vfd = &vid_dev->ve.vdev;
+	int ret;
+
+	memset(vfd, 0, sizeof(*vfd));
+
+	strlcpy(vfd->name, VIDEO_DEVICE_NAME, sizeof(vfd->name));
+
+	vfd->fops = &vid_dev_fops;
+	vfd->ioctl_ops = &vid_dev_ioctl_ops;
+	vfd->v4l2_dev = sd->v4l2_dev;
+	vfd->minor = -1;
+	vfd->release = video_device_release_empty;
+	vfd->queue = q;
+
+	INIT_LIST_HEAD(&vid_dev->vidq.active);
+	init_waitqueue_head(&vid_dev->vidq.wq);
+	memset(q, 0, sizeof(*q));
+	q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+	q->io_modes = VB2_MMAP | VB2_USERPTR;
+	q->ops = &vb2_video_qops;
+	q->mem_ops = &vb2_vmalloc_memops;
+	q->buf_struct_size = sizeof(struct rx_buffer);
+	q->drv_priv = vid_dev;
+	q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+	q->lock = &vid_dev->lock;
+
+	ret = vb2_queue_init(q);
+	if (ret < 0)
+		return ret;
+
+	vid_dev->vd_pad.flags = MEDIA_PAD_FL_SINK;
+	ret = media_entity_pads_init(&vfd->entity, 1, &vid_dev->vd_pad);
+	if (ret < 0)
+		return ret;
+
+	video_set_drvdata(vfd, vid_dev);
+	vid_dev->ve.pipe = v4l2_get_subdev_hostdata(sd);
+
+	ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
+	if (ret < 0) {
+		media_entity_cleanup(&vfd->entity);
+		vid_dev->ve.pipe = NULL;
+		return ret;
+	}
+
+	v4l2_info(sd->v4l2_dev, "Registered %s as /dev/%s\n",
+		  vfd->name, video_device_node_name(vfd));
+	return 0;
+}
+
+static void vid_dev_subdev_unregistered(struct v4l2_subdev *sd)
+{
+	struct video_device_dev *vid_dev = v4l2_get_subdevdata(sd);
+
+	if (vid_dev == NULL)
+		return;
+
+	mutex_lock(&vid_dev->lock);
+
+	if (video_is_registered(&vid_dev->ve.vdev)) {
+		video_unregister_device(&vid_dev->ve.vdev);
+		media_entity_cleanup(&vid_dev->ve.vdev.entity);
+		vid_dev->ve.pipe = NULL;
+	}
+
+	mutex_unlock(&vid_dev->lock);
+}
+
+static const struct v4l2_subdev_internal_ops vid_dev_subdev_internal_ops = {
+	.registered = vid_dev_subdev_registered,
+	.unregistered = vid_dev_subdev_unregistered,
+};
+
+static const struct v4l2_subdev_core_ops vid_dev_subdev_core_ops = {
+	.s_power = vid_dev_subdev_s_power,
+};
+
+static struct v4l2_subdev_ops vid_dev_subdev_ops = {
+	.core = &vid_dev_subdev_core_ops,
+};
+
+static int vid_dev_create_capture_subdev(struct video_device_dev *vid_dev)
+{
+	struct v4l2_subdev *sd = &vid_dev->subdev;
+	int ret;
+
+	v4l2_subdev_init(sd, &vid_dev_subdev_ops);
+	sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+	snprintf(sd->name, sizeof(sd->name), "Capture device");
+
+	vid_dev->subdev_pads[VIDEO_DEV_SD_PAD_SINK_CSI].flags =
+		MEDIA_PAD_FL_SOURCE;
+	vid_dev->subdev_pads[VIDEO_DEV_SD_PAD_SOURCE_DMA].flags =
+		MEDIA_PAD_FL_SINK;
+	ret = media_entity_pads_init(&sd->entity, VIDEO_DEV_SD_PADS_NUM,
+				   vid_dev->subdev_pads);
+	if (ret)
+		return ret;
+
+	sd->internal_ops = &vid_dev_subdev_internal_ops;
+	sd->owner = THIS_MODULE;
+	v4l2_set_subdevdata(sd, vid_dev);
+
+	return 0;
+}
+
+static void vid_dev_unregister_subdev(struct video_device_dev *vid_dev)
+{
+	struct v4l2_subdev *sd = &vid_dev->subdev;
+
+	v4l2_device_unregister_subdev(sd);
+	media_entity_cleanup(&sd->entity);
+	v4l2_set_subdevdata(sd, NULL);
+}
+
+static const struct of_device_id vid_dev_of_match[];
+
+static int vid_dev_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct of_device_id *of_id;
+	int ret = 0;
+	struct video_device_dev *vid_dev;
+
+	dev_dbg(dev, "Installing IPK Video Device module\n");
+
+	if (!dev->of_node)
+		return -ENODEV;
+
+	vid_dev = devm_kzalloc(dev, sizeof(*vid_dev), GFP_KERNEL);
+	if (!vid_dev)
+		return -ENOMEM;
+
+	of_id = of_match_node(vid_dev_of_match, dev->of_node);
+	if (WARN_ON(of_id == NULL))
+		return -EINVAL;
+
+	vid_dev->pdev = pdev;
+
+	spin_lock_init(&vid_dev->slock);
+	mutex_init(&vid_dev->lock);
+
+	dev_dbg(&pdev->dev, "Requesting DMA\n");
+	vid_dev->dma = dma_request_slave_channel(&pdev->dev, "vdma0");
+	if (vid_dev->dma == NULL) {
+		dev_err(&pdev->dev, "no VDMA channel found\n");
+		ret = -ENODEV;
+		goto end;
+	}
+
+	ret = vid_dev_create_capture_subdev(vid_dev);
+	if (ret)
+		goto end;
+
+	platform_set_drvdata(pdev, vid_dev);
+
+	dev_info(dev, "Video Device registered successfully\n");
+	return 0;
+end:
+	dev_err(dev, "Video Device not registered!!\n");
+	return ret;
+}
+
+static int vid_dev_remove(struct platform_device *pdev)
+{
+	struct video_device_dev *dev = platform_get_drvdata(pdev);
+
+	vid_dev_unregister_subdev(dev);
+	dev_info(&pdev->dev, "Driver removed\n");
+
+	return 0;
+}
+
+static const struct of_device_id vid_dev_of_match[] = {
+	{.compatible = "snps,video-device"},
+	{}
+};
+
+MODULE_DEVICE_TABLE(of, vid_dev_of_match);
+
+static struct platform_driver __refdata vid_dev_pdrv = {
+	.remove = vid_dev_remove,
+	.probe = vid_dev_probe,
+	.driver = {
+		   .name = VIDEO_DEVICE_NAME,
+		   .owner = THIS_MODULE,
+		   .of_match_table = vid_dev_of_match,
+		   },
+};
+
+module_platform_driver(vid_dev_pdrv);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>");
+MODULE_DESCRIPTION("Driver for configuring DMA and Video Device");
diff --git a/drivers/media/platform/dwc/video_device.h b/drivers/media/platform/dwc/video_device.h
new file mode 100644
index 0000000..2d8a1a0
--- /dev/null
+++ b/drivers/media/platform/dwc/video_device.h
@@ -0,0 +1,85 @@
+/*
+ * Copyright (C) 2016 Synopsys, Inc. All rights reserved.
+ *
+ * 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 VIDEO_DEVICE_H_
+#define VIDEO_DEVICE_H_
+
+#include <linux/delay.h>
+#include <linux/dma/xilinx_dma.h>
+#include <linux/errno.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/videodev2.h>
+#include <linux/wait.h>
+#include <media/media-entity.h>
+#include <media/v4l2-common.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-fh.h>
+#include <media/v4l2-ioctl.h>
+#include <media/videobuf2-vmalloc.h>
+
+
+
+#include "plat_ipk_video.h"
+
+#define N_BUFFERS 3
+
+#define VIDEO_DEVICE_NAME	"video-device"
+
+#define FUNC_NAME __func__
+
+struct rx_buffer {
+	/** @short Buffer for video frames */
+	struct vb2_v4l2_buffer vb;
+	struct list_head list;
+
+	dma_addr_t dma_addr;
+	void *cpu_addr;
+};
+
+struct dmaqueue {
+	struct list_head active;
+	wait_queue_head_t wq;
+};
+
+/**
+ * @short Structure to embed device driver information
+ */
+struct video_device_dev {
+	struct platform_device *pdev;
+	struct v4l2_device *v4l2_dev;
+	struct v4l2_subdev subdev;
+	struct media_pad vd_pad;
+	struct media_pad subdev_pads[VIDEO_DEV_SD_PADS_NUM];
+	struct mutex lock;
+	spinlock_t slock;
+	struct plat_ipk_video_entity ve;
+	struct v4l2_format format;
+	struct v4l2_pix_format pix_format;
+	const struct plat_ipk_fmt *fmt;
+	unsigned long *alloc_ctx;
+
+	/* Buffer and DMA */
+	struct vb2_queue vb_queue;
+	int idx;
+	int last_idx;
+	struct dmaqueue vidq;
+	struct rx_buffer dma_buf[N_BUFFERS];
+	struct dma_chan *dma;
+	struct dma_interleaved_template xt;
+	struct data_chunk sgl[1];
+};
+
+#endif				/* VIDEO_DEVICE_H_ */
-- 
2.10.2


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

^ permalink raw reply related

* Re: [PATCH v5 1/2] Add OV5647 device tree documentation
From: Sakari Ailus @ 2016-12-12 15:12 UTC (permalink / raw)
  To: Ramiro Oliveira
  Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-media-u79uwXL29TY76Z2rM5mHXA,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
	linux-0h96xk9xTtrk1uMJSBkQmQ, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
	dheitmueller-eb9eJ82Ua7k9XoPSrs7Ehg,
	slongerbeam-Re5JQEeQqe8AvxtiuMwx3w, lars-Qo5EllUWu/uELgA04lAiVw,
	robert.jarzmik-GANU6spQydw, pavel-+ZI9xUNit7I,
	pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
	sakari.ailus-VuQAYsv1563Yd54FQh9/CA, mark.rutland-5wv7dgnIgG8,
	CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <db9fcc03-9db0-856a-8fbd-e641862f9bc8-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>

Hi Ramiro,

On Mon, Dec 12, 2016 at 01:07:53PM +0000, Ramiro Oliveira wrote:
> Hi Sakari
> 
> On 12/12/2016 12:19 PM, Sakari Ailus wrote:
> > Hi Ramiro,
> > 
> > On Mon, Dec 12, 2016 at 12:15:04PM +0000, Ramiro Oliveira wrote:
> >> Hi Sakari
> >>
> >> On 12/12/2016 11:49 AM, Sakari Ailus wrote:
> >>> Hi Ramiro,
> >>>
> >>> On Mon, Dec 12, 2016 at 11:39:31AM +0000, Ramiro Oliveira wrote:
> >>>> Hi Sakari,
> >>>>
> >>>> Thank you for the feedback.
> >>>>
> >>>> On 12/7/2016 10:33 PM, Sakari Ailus wrote:
> >>>>> Hi Ramiro,
> >>>>>
> >>>>> Thank you for the patch.
> >>>>>
> >>>>> On Mon, Dec 05, 2016 at 05:36:33PM +0000, Ramiro Oliveira wrote:
> >>>>>> Add device tree documentation.
> >>>>>>
> >>>>>> Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> >>>>>> ---
> >>>>>>  .../devicetree/bindings/media/i2c/ov5647.txt          | 19 +++++++++++++++++++
> >>>>>>  1 file changed, 19 insertions(+)
> >>>>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>>>> new file mode 100644
> >>>>>> index 0000000..4c91b3b
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> >>>>>> @@ -0,0 +1,19 @@
> >>>>>> +Omnivision OV5647 raw image sensor
> >>>>>> +---------------------------------
> >>>>>> +
> >>>>>> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> >>>>>> +and CCI (I2C compatible) control bus.
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +
> >>>>>> +- compatible	: "ovti,ov5647";
> >>>>>> +- reg		: I2C slave address of the sensor;
> >>>>>> +
> >>>>>> +The common video interfaces bindings (see video-interfaces.txt) should be
> >>>>>> +used to specify link to the image data receiver. The OV5647 device
> >>>>>> +node should contain one 'port' child node with an 'endpoint' subnode.
> >>>>>> +
> >>>>>> +Following properties are valid for the endpoint node:
> >>>>>> +
> >>>>>> +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
> >>>>>> +  video-interfaces.txt.  The sensor supports only two data lanes.
> >>>>>
> >>>>> Doesn't this sensor require a external clock, a reset GPIO and / or a
> >>>>> regulator or a few? Do you need data-lanes, unless you can change the order
> >>>>> or the number?
> >>>>
> >>>> In the setup I'm using, I'm not aware of any reset GPIO or regulator. I do use a
> >>>> external clock but it's fixed and not controlled by SW. Should I add a property
> >>>> for this?
> >>>
> >>> The sensor datasheet defines a power-up and power-down sequence for the
> >>> device. If you don't implement these sequences in the driver on a DT based
> >>> system, nothing suggests that they're implemented correctly. Could it be
> >>> that the boot loader simply enables the regulators or another device
> >>> requires them to be enabled?
> >>>
> >>> I presume at least the reset GPIO should be controlled explicitly in order
> >>> to ensure correct function. Although hardware can be surprising: I have one
> >>> production system that has no reset GPIO for the sensor albeit the sensor
> >>> datasheet says that's part of the power up sequence.
> >>>
> >>
> >> Sorry for the misunderstanding. I wanted to say that, there is no SW controlled
> >> reset. In the board we're using to connect the sensor to our D-PHY we have a
> >> GPIO controller that when it receives power, it removes the sensor from reset,
> >> so I have no control over that.
> > 
> > Do you mean to say that there's a GPIO controller but there's not (yet?) a
> > driver for that or that the reset line is actually hard-wired to something
> > else?
> > 
> 
> The reset line is hardwired to a GPIO controller that when powered-on removes
> the sensor from reset. However I have no control over the GPIO controller.

A GPIO controller is a piece of hardware that lets software to, typically,
both configure the direction and change and read the state of its input /
output pins. You seem to have something else on the board, such as chip
giving a power good signal.

If there really is no software control to to these resources, I suggest not
to implement the power up / down sequences as you can't test them anyway. We
can always add the DT properties (as optional) to the DT documentation.

You still should have the clock frequency in DT and check that in the
driver, even if you don't get a clock. Presumably your current register
lists assume a particular frequency but AFAIR that wasn't clearly visible
anywhere.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org	XMPP: sailus-PCDdDYkjdNMDXYZnReoRVg@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 1/2] of: base: add support to get machine model name
From: Rob Herring @ 2016-12-12 15:17 UTC (permalink / raw)
  To: Frank Rowand
  Cc: Sudeep Holla,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <584B442D.4020104-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Fri, Dec 9, 2016 at 5:54 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 12/09/16 08:03, Rob Herring wrote:
>> On Wed, Nov 23, 2016 at 4:25 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>>>
>>>
>>> On 22/11/16 21:35, Rob Herring wrote:
>>>>
>>>> On Tue, Nov 22, 2016 at 12:44 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> wrote:
>>>
>>>
>>> [...]
>>>
>>>>>
>>>>> This patch adds a function that leads to conflating the "model" property
>>>>> and the "compatible" property. This leads to opaque, confusing and
>>>>> unclear
>>>>> code where ever it is used.   I think it is not good for the device tree
>>>>> framework to contribute to writing unclear code.
>>>>>
>>>>> Further, only two of the proposed users of this new function appear to
>>>>> be proper usage.  I do not think that the small amount of reduced lines
>>>>> of code is a good trade off for the reduced code clarity and for the
>>>>> potential for future mis-use of this function.
>>>>>
>>>>> Can I convince you to revert this patch?
>>>>
>>>>
>>>> Yes, I will revert.
>>
>> I looked at this again and the users. They are all informational, so
>
> A comment in the function docbook header stating that the intent of the
> returned value is for informational use only would make me happy.
>
> There is at least on proposed use in patch 2/2 that is not just
> informational.  init_octeon_system_type() sometimes uses the value of
> the model property to create the value of variable octeon_system_type.
> octeon_pcie_pcibios_map_irq() checks the value of octeon_system_type
> (via the function octeon_board_type_string()) to determine whether
> to apply a fixup:
>
> int __init octeon_pcie_pcibios_map_irq(const struct pci_dev *dev,
>                                        u8 slot, u8 pin)
> {
>         /*
>          * The EBH5600 board with the PCI to PCIe bridge mistakenly
>          * wires the first slot for both device id 2 and interrupt
>          * A. According to the PCI spec, device id 2 should be C. The
>          * following kludge attempts to fix this.
>          */
>         if (strstr(octeon_board_type_string(), "EBH5600") &&
>             dev->bus && dev->bus->parent) {

True, it is more than informational, but let's think about what would
have to happen for the change here to matter. We would have to have a
board with no model property. Then we'd have to have a compatible
string of "EBH5600" on a board which is not the same one as model
EBH5600 and wouldn't be valid anyway with no vendor prefix. IMO, this
code should be using of_machine_is_compatible() anyway. MIPS SoC and
board code is a mess anyway. Linus needs to yell at them.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 3/6] mfd: dt: Add Aspeed Low Pin Count Controller bindings
From: Rob Herring @ 2016-12-12 15:28 UTC (permalink / raw)
  To: Andrew Jeffery
  Cc: Lee Jones, Mark Rutland, Linus Walleij, Corey Minyard,
	Cédric Le Goater, Joel Stanley, devicetree, linux-arm-kernel,
	linux-kernel
In-Reply-To: <20161206025321.1792-4-andrew@aj.id.au>

On Tue, Dec 06, 2016 at 01:53:18PM +1100, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
>  .../devicetree/bindings/mfd/aspeed-lpc.txt         | 111 +++++++++++++++++++++
>  1 file changed, 111 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v3 4/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
From: Rob Herring @ 2016-12-12 15:30 UTC (permalink / raw)
  To: Andrew Jeffery
  Cc: Lee Jones, Mark Rutland, Linus Walleij, Corey Minyard,
	Cédric Le Goater, Joel Stanley,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161206025321.1792-5-andrew-zrmu5oMJ5Fs@public.gmane.org>

On Tue, Dec 06, 2016 at 01:53:19PM +1100, Andrew Jeffery wrote:
> The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> on bits in both the System Control Unit and the LPC Host Controller.
> 
> The Aspeed LPC Host Controller is described as a child node of the
> LPC host-range syscon device for arbitration of access by the host
> controller and pinmux drivers.
> 
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
> ---
>  .../devicetree/bindings/mfd/aspeed-lpc.txt         | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> index a97131aba446..9de318ef72da 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -109,3 +109,25 @@ lpc: lpc@1e789000 {
>  	};
>  };
>  
> +Host Node Children
> +==================
> +
> +LPC Host Controller
> +-------------------
> +
> +The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
> +between the host and the baseboard management controller. The registers exist
> +in the "host" portion of the Aspeed LPC controller, which must be the parent of
> +the LPC host controller node.
> +
> +Required properties:
> +- compatible:		"aspeed,ast2500-lhc";
> +- reg:			contains offset/length value of the LHC memory
> +			region.

How many regions? Looks like 2.

> +
> +Example:
> +
> +lhc: lhc@20 {
> +	compatible = "aspeed,ast2500-lhc";
> +	reg = <0x20 0x24 0x48 0x8>;
> +};
> -- 
> 2.9.3
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory
From: Rob Herring @ 2016-12-12 15:39 UTC (permalink / raw)
  To: Andrew Jeffery
  Cc: Lee Jones, Mark Rutland, Linus Walleij, Corey Minyard,
	Cédric Le Goater, Joel Stanley,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161206025321.1792-7-andrew-zrmu5oMJ5Fs@public.gmane.org>

On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> The use of syscons is growing, lets collate them in their own part of
> the bindings tree.
> 
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt         | 0
>  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt         | 0
>  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt       | 0
>  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt          | 0
>  Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt          | 0
>  Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt             | 0
>  .../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt          | 0
>  7 files changed, 0 insertions(+), 0 deletions(-)
>  rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt (100%)
>  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt (100%)
>  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt (100%)
>  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt (100%)
>  rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt (100%)
>  rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
>  rename Documentation/devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt (100%)

I'm not so sure this is the right direction. syscon usage is pretty much 
spread throughout the tree.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH v4 0/4] Static memory controllers for the Aspeed SoC
From: Cédric Le Goater @ 2016-12-12 15:40 UTC (permalink / raw)
  To: linux-mtd
  Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
	Marek Vasut, Rob Herring, Joel Stanley, Cyrille Pitchen,
	Brian Norris, David Woodhouse, Cédric Le Goater

Hello,

Here is a series introducing a new driver for the different memory
controllers of the Aspeed AST2500 and AST2400 SoCs. Each SoC has at
least a memory controller for the BMC firmware and another one for the
host firmware. The register set are mostly compatible but there are
some slight differences on the AST2400.

The driver only supports SPI type flash.

Tested on:

 * OpenPOWER Palmetto (AST2400) with
 	FMC controller : n25q256a
	SPI controller : mx25l25635e and n25q512ax3

 * Evaluation board (AST2500) with
 	FMC controller : w25q256 
	SPI controller : w25q256

 * OpenPOWER Witherspoon (AST2500) with
 	FMC controller : mx25l25635e * 2
	SPI controller : mx66l1g45g

Changes since v3:
 - reworked IO routines to use io{read,write}32_rep
 - changed config option to SPI_ASPEED_SMC
 - fixed aspeed_smc_chip_setup_init() returned value

Changes since v2:
 - splitted patch to distinguish AST2400 and AST2500 controllers
 - fixed controller names
 - introduced prepare/unprepare ops
 - introduced a aspeed_smc_setup_flash() routine
 - various cleanups

Changes since v1:
 - added a set4b ops to handle difference in the controllers
 - simplified the IO routines
 - prepared for fast read using dummy cycles

Work in progress:
 - read optimization using higher SPI clock frequencies
 - command mode to direct reads from AHB
 - DMA support

Thanks,

C.

Cédric Le Goater (4):
  mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
  mtd: aspeed: add memory controllers for the Aspeed AST2400 SoC
  mtd: spi-nor: bindings for the Aspeed memory controllers
  mtd: spi-nor: add a label property to jedec,spi-nor

 .../devicetree/bindings/mtd/aspeed-smc.txt         |  51 ++
 .../devicetree/bindings/mtd/jedec,spi-nor.txt      |   2 +
 drivers/mtd/spi-nor/Kconfig                        |  10 +
 drivers/mtd/spi-nor/Makefile                       |   1 +
 drivers/mtd/spi-nor/aspeed-smc.c                   | 752 +++++++++++++++++++++
 5 files changed, 816 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/aspeed-smc.txt
 create mode 100644 drivers/mtd/spi-nor/aspeed-smc.c

-- 
2.7.4


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* [PATCH v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Cédric Le Goater @ 2016-12-12 15:40 UTC (permalink / raw)
  To: linux-mtd
  Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
	Marek Vasut, Rob Herring, Joel Stanley, Cyrille Pitchen,
	Brian Norris, David Woodhouse, Cédric Le Goater
In-Reply-To: <1481557252-13656-1-git-send-email-clg@kaod.org>

This driver adds mtd support for the Aspeed AST2500 SoC static memory
controllers :

 * Firmware SPI Memory Controller (FMC)
   . BMC firmware
   . 3 chip select pins (CE0 ~ CE2)
   . supports SPI type flash memory (CE0-CE1)
   . CE2 can be of NOR type flash but this is not supported by the
     driver

 * SPI Flash Controller (SPI1 and SPI2)
   . host firmware
   . 2 chip select pins (CE0 ~ CE1)
   . supports SPI type flash memory

Each controller has a memory range on which it maps its flash module
slaves. Each slave is assigned a memory window for its mapping that
can be changed at bootime with the Segment Address Register.

Each SPI flash slave can then be accessed in two modes: Command and
User. When in User mode, accesses to the memory segment of the slaves
are translated in SPI transfers. When in Command mode, the HW
generates the SPI commands automatically and the memory segment is
accessed as if doing a MMIO.

Currently, only the User mode is supported. Command mode needs a
little more work to check that the memory window on the AHB bus fits
the module size.

Based on previous work from Milton D. Miller II <miltonm@us.ibm.com>

Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
---

Changes since v3:
 - reworked IO routines to use io{read,write}32_rep
 - changed config option to SPI_ASPEED_SMC
 - fixed aspeed_smc_chip_setup_init() returned value
 - merged the use of the "label" property"

 drivers/mtd/spi-nor/Kconfig      |  10 +
 drivers/mtd/spi-nor/Makefile     |   1 +
 drivers/mtd/spi-nor/aspeed-smc.c | 719 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 730 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/aspeed-smc.c

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 4a682ee0f632..42168e9d6097 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -29,6 +29,16 @@ config MTD_SPI_NOR_USE_4K_SECTORS
 	  Please note that some tools/drivers/filesystems may not work with
 	  4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum).
 
+config SPI_ASPEED_SMC
+	tristate "Aspeed flash controllers in SPI mode"
+	depends on ARCH_ASPEED || COMPILE_TEST
+	depends on HAS_IOMEM && OF
+	help
+	  This enables support for the Firmware Memory controller (FMC)
+	  in the Aspeed AST2500 SoC when attached to SPI NOR chips,
+	  and support for the SPI flash memory controller (SPI) for
+	  the host firmware. The implementation only supports SPI NOR.
+
 config SPI_ATMEL_QUADSPI
 	tristate "Atmel Quad SPI Controller"
 	depends on ARCH_AT91 || (ARM && COMPILE_TEST)
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 121695e83542..6ff64bc7fa0e 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_MTD_SPI_NOR)	+= spi-nor.o
+obj-$(CONFIG_SPI_ASPEED_SMC)	+= aspeed-smc.o
 obj-$(CONFIG_SPI_ATMEL_QUADSPI)	+= atmel-quadspi.o
 obj-$(CONFIG_SPI_CADENCE_QUADSPI)	+= cadence-quadspi.o
 obj-$(CONFIG_SPI_FSL_QUADSPI)	+= fsl-quadspi.o
diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
new file mode 100644
index 000000000000..2667ab7aeb9b
--- /dev/null
+++ b/drivers/mtd/spi-nor/aspeed-smc.c
@@ -0,0 +1,719 @@
+/*
+ * ASPEED Static Memory Controller driver
+ *
+ * Copyright (c) 2015-2016, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/bug.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/spi-nor.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/sysfs.h>
+
+#define DEVICE_NAME	"aspeed-smc"
+
+/*
+ * The driver only support SPI flash
+ */
+enum aspeed_smc_flash_type {
+	smc_type_nor  = 0,
+	smc_type_nand = 1,
+	smc_type_spi  = 2,
+};
+
+struct aspeed_smc_chip;
+
+struct aspeed_smc_info {
+	u32 maxsize;		/* maximum size of chip window */
+	u8 nce;			/* number of chip enables */
+	bool hastype;		/* flash type field exists in config reg */
+	u8 we0;			/* shift for write enable bit for CE0 */
+	u8 ctl0;		/* offset in regs of ctl for CE0 */
+
+	void (*set_4b)(struct aspeed_smc_chip *chip);
+};
+
+static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip);
+
+static const struct aspeed_smc_info fmc_2500_info = {
+	.maxsize = 256 * 1024 * 1024,
+	.nce = 3,
+	.hastype = true,
+	.we0 = 16,
+	.ctl0 = 0x10,
+	.set_4b = aspeed_smc_chip_set_4b,
+};
+
+static const struct aspeed_smc_info spi_2500_info = {
+	.maxsize = 128 * 1024 * 1024,
+	.nce = 2,
+	.hastype = false,
+	.we0 = 16,
+	.ctl0 = 0x10,
+	.set_4b = aspeed_smc_chip_set_4b,
+};
+
+enum aspeed_smc_ctl_reg_value {
+	smc_base,		/* base value without mode for other commands */
+	smc_read,		/* command reg for (maybe fast) reads */
+	smc_write,		/* command reg for writes */
+	smc_max,
+};
+
+struct aspeed_smc_controller;
+
+struct aspeed_smc_chip {
+	int cs;
+	struct aspeed_smc_controller *controller;
+	void __iomem *ctl;			/* control register */
+	void __iomem *ahb_base;			/* base of chip window */
+	u32 ctl_val[smc_max];			/* control settings */
+	enum aspeed_smc_flash_type type;	/* what type of flash */
+	struct spi_nor nor;
+};
+
+struct aspeed_smc_controller {
+	struct device *dev;
+
+	struct mutex mutex;			/* controller access mutex */
+	const struct aspeed_smc_info *info;	/* type info of controller */
+	void __iomem *regs;			/* controller registers */
+	void __iomem *ahb_base;			/* per-chip windows resource */
+
+	struct aspeed_smc_chip *chips[0];	/* pointers to attached chips */
+};
+
+/*
+ * SPI Flash Configuration Register (AST2500 SPI)
+ *     or
+ * Type setting Register (AST2500 FMC).
+ * CE0 and CE1 can only be of type SPI. CE2 can be of type NOR but the
+ * driver does not support it.
+ */
+#define CONFIG_REG			0x0
+#define CONFIG_DISABLE_LEGACY		BIT(31) /* 1 */
+
+#define CONFIG_CE2_WRITE		BIT(18)
+#define CONFIG_CE1_WRITE		BIT(17)
+#define CONFIG_CE0_WRITE		BIT(16)
+
+#define CONFIG_CE2_TYPE			BIT(4) /* AST2500 FMC only */
+#define CONFIG_CE1_TYPE			BIT(2) /* AST2500 FMC only */
+#define CONFIG_CE0_TYPE			BIT(0) /* AST2500 FMC only */
+
+/*
+ * CE Control Register
+ */
+#define CE_CONTROL_REG			0x4
+
+/*
+ * CEx Control Register
+ */
+#define CONTROL_AAF_MODE		BIT(31)
+#define CONTROL_IO_MODE_MASK		GENMASK(30, 28)
+#define CONTROL_IO_DUAL_DATA		BIT(29)
+#define CONTROL_IO_DUAL_ADDR_DATA	(BIT(29) | BIT(28))
+#define CONTROL_IO_QUAD_DATA		BIT(30)
+#define CONTROL_IO_QUAD_ADDR_DATA	(BIT(30) | BIT(28))
+#define CONTROL_CE_INACTIVE_SHIFT	24
+#define CONTROL_CE_INACTIVE_MASK	GENMASK(27, \
+					CONTROL_CE_INACTIVE_SHIFT)
+/* 0 = 16T ... 15 = 1T   T=HCLK */
+#define CONTROL_COMMAND_SHIFT		16
+#define CONTROL_DUMMY_COMMAND_OUT	BIT(15)
+#define CONTROL_IO_DUMMY_HI		BIT(14)
+#define CONTROL_IO_DUMMY_HI_SHIFT	14
+#define CONTROL_CLK_DIV4		BIT(13) /* others */
+#define CONTROL_RW_MERGE		BIT(12)
+#define CONTROL_IO_DUMMY_LO_SHIFT	6
+#define CONTROL_IO_DUMMY_LO		GENMASK(7, \
+						CONTROL_IO_DUMMY_LO_SHIFT)
+#define CONTROL_IO_DUMMY_MASK		(CONTROL_IO_DUMMY_HI | \
+					 CONTROL_IO_DUMMY_LO)
+#define CONTROL_IO_DUMMY_SET(dummy)				 \
+	(((((dummy) >> 2) & 0x1) << CONTROL_IO_DUMMY_HI_SHIFT) | \
+	 (((dummy) & 0x3) << CONTROL_IO_DUMMY_LO_SHIFT))
+
+#define CONTROL_CLOCK_FREQ_SEL_SHIFT	8
+#define CONTROL_CLOCK_FREQ_SEL_MASK	GENMASK(11, \
+						CONTROL_CLOCK_FREQ_SEL_SHIFT)
+#define CONTROL_LSB_FIRST		BIT(5)
+#define CONTROL_CLOCK_MODE_3		BIT(4)
+#define CONTROL_IN_DUAL_DATA		BIT(3)
+#define CONTROL_CE_STOP_ACTIVE_CONTROL	BIT(2)
+#define CONTROL_COMMAND_MODE_MASK	GENMASK(1, 0)
+#define CONTROL_COMMAND_MODE_NORMAL	0
+#define CONTROL_COMMAND_MODE_FREAD	1
+#define CONTROL_COMMAND_MODE_WRITE	2
+#define CONTROL_COMMAND_MODE_USER	3
+
+#define CONTROL_KEEP_MASK						\
+	(CONTROL_AAF_MODE | CONTROL_CE_INACTIVE_MASK | CONTROL_CLK_DIV4 | \
+	 CONTROL_IO_DUMMY_MASK | CONTROL_CLOCK_FREQ_SEL_MASK |		\
+	 CONTROL_LSB_FIRST | CONTROL_CLOCK_MODE_3)
+
+/*
+ * The Segment Register uses a 8MB unit to encode the start address
+ * and the end address of the mapping window of a flash SPI slave :
+ *
+ *        | byte 1 | byte 2 | byte 3 | byte 4 |
+ *        +--------+--------+--------+--------+
+ *        |  end   |  start |   0    |   0    |
+ */
+#define SEGMENT_ADDR_REG0		0x30
+#define SEGMENT_ADDR_START(_r)		((((_r) >> 16) & 0xFF) << 23)
+#define SEGMENT_ADDR_END(_r)		((((_r) >> 24) & 0xFF) << 23)
+
+/*
+ * In user mode all data bytes read or written to the chip decode address
+ * range are transferred to or from the SPI bus. The range is treated as a
+ * fifo of arbitratry 1, 2, or 4 byte width but each write has to be aligned
+ * to its size. The address within the multiple 8kB range is ignored when
+ * sending bytes to the SPI bus.
+ *
+ * On the arm architecture, as of Linux version 4.3, memcpy_fromio and
+ * memcpy_toio on little endian targets use the optimized memcpy routines
+ * that were designed for well behavied memory storage. These routines
+ * have a stutter if the source and destination are not both word aligned,
+ * once with a duplicate access to the source after aligning to the
+ * destination to a word boundary, and again with a duplicate access to
+ * the source when the final byte count is not word aligned.
+ *
+ * When writing or reading the fifo this stutter discards data or sends
+ * too much data to the fifo and can not be used by this driver.
+ *
+ * While the low level io string routines that implement the insl family do
+ * the desired accesses and memory increments, the cross architecture io
+ * macros make them essentially impossible to use on a memory mapped address
+ * instead of a a token from the call to iomap of an io port.
+ *
+ * These fifo routines use readl and friends to a constant io port and update
+ * the memory buffer pointer and count via explicit code. The final updates
+ * to len are optimistically suppressed.
+ */
+static int aspeed_smc_read_from_ahb(void *buf, const void __iomem *src,
+				    size_t len)
+{
+	if (IS_ALIGNED((uintptr_t)src, sizeof(uintptr_t)) &&
+	    IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t)) &&
+	    IS_ALIGNED(len, sizeof(u32))) {
+		ioread32_rep(src, buf, len >> 2);
+	} else {
+		ioread8_rep(src, buf, len);
+	}
+	return 0;
+}
+
+static int aspeed_smc_write_to_ahb(void __iomem *dst, const void *buf,
+				   size_t len)
+{
+	if (IS_ALIGNED((uintptr_t)dst, sizeof(uintptr_t)) &&
+	    IS_ALIGNED((uintptr_t)buf, sizeof(uintptr_t)) &&
+	    IS_ALIGNED(len, sizeof(u32))) {
+		iowrite32_rep(dst, buf, len >> 2);
+	} else {
+		iowrite8_rep(dst, buf, len);
+	}
+	return 0;
+}
+
+static inline u32 aspeed_smc_chip_write_bit(struct aspeed_smc_chip *chip)
+{
+	return BIT(chip->controller->info->we0 + chip->cs);
+}
+
+static void aspeed_smc_chip_check_config(struct aspeed_smc_chip *chip)
+{
+	struct aspeed_smc_controller *controller = chip->controller;
+	u32 reg;
+
+	reg = readl(controller->regs + CONFIG_REG);
+
+	if (reg & aspeed_smc_chip_write_bit(chip))
+		return;
+
+	dev_dbg(controller->dev, "config write is not set ! @%p: 0x%08x\n",
+		controller->regs + CONFIG_REG, reg);
+	reg |= aspeed_smc_chip_write_bit(chip);
+	writel(reg, controller->regs + CONFIG_REG);
+}
+
+static void aspeed_smc_start_user(struct spi_nor *nor)
+{
+	struct aspeed_smc_chip *chip = nor->priv;
+	u32 ctl = chip->ctl_val[smc_base];
+
+	/*
+	 * When the chip is controlled in user mode, we need write
+	 * access to send the opcodes to it. So check the config.
+	 */
+	aspeed_smc_chip_check_config(chip);
+
+	ctl |= CONTROL_COMMAND_MODE_USER |
+		CONTROL_CE_STOP_ACTIVE_CONTROL;
+	writel(ctl, chip->ctl);
+
+	ctl &= ~CONTROL_CE_STOP_ACTIVE_CONTROL;
+	writel(ctl, chip->ctl);
+}
+
+static void aspeed_smc_stop_user(struct spi_nor *nor)
+{
+	struct aspeed_smc_chip *chip = nor->priv;
+
+	u32 ctl = chip->ctl_val[smc_read];
+	u32 ctl2 = ctl | CONTROL_COMMAND_MODE_USER |
+		CONTROL_CE_STOP_ACTIVE_CONTROL;
+
+	writel(ctl2, chip->ctl);	/* stop user CE control */
+	writel(ctl, chip->ctl);		/* default to fread or read mode */
+}
+
+static int aspeed_smc_prep(struct spi_nor *nor, enum spi_nor_ops ops)
+{
+	struct aspeed_smc_chip *chip = nor->priv;
+
+	mutex_lock(&chip->controller->mutex);
+	return 0;
+}
+
+static void aspeed_smc_unprep(struct spi_nor *nor, enum spi_nor_ops ops)
+{
+	struct aspeed_smc_chip *chip = nor->priv;
+
+	mutex_unlock(&chip->controller->mutex);
+}
+
+static int aspeed_smc_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
+{
+	struct aspeed_smc_chip *chip = nor->priv;
+
+	aspeed_smc_start_user(nor);
+	aspeed_smc_write_to_ahb(chip->ahb_base, &opcode, 1);
+	aspeed_smc_read_from_ahb(buf, chip->ahb_base, len);
+	aspeed_smc_stop_user(nor);
+	return 0;
+}
+
+static int aspeed_smc_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
+				int len)
+{
+	struct aspeed_smc_chip *chip = nor->priv;
+
+	aspeed_smc_start_user(nor);
+	aspeed_smc_write_to_ahb(chip->ahb_base, &opcode, 1);
+	aspeed_smc_write_to_ahb(chip->ahb_base, buf, len);
+	aspeed_smc_stop_user(nor);
+	return 0;
+}
+
+static void aspeed_smc_send_cmd_addr(struct spi_nor *nor, u8 cmd, u32 addr)
+{
+	struct aspeed_smc_chip *chip = nor->priv;
+	__be32 temp;
+	u32 cmdaddr;
+
+	switch (nor->addr_width) {
+	default:
+		WARN_ONCE(1, "Unexpected address width %u, defaulting to 3\n",
+			  nor->addr_width);
+		/* FALLTHROUGH */
+	case 3:
+		cmdaddr = addr & 0xFFFFFF;
+		cmdaddr |= cmd << 24;
+
+		temp = cpu_to_be32(cmdaddr);
+		aspeed_smc_write_to_ahb(chip->ahb_base, &temp, 4);
+		break;
+	case 4:
+		temp = cpu_to_be32(addr);
+		aspeed_smc_write_to_ahb(chip->ahb_base, &cmd, 1);
+		aspeed_smc_write_to_ahb(chip->ahb_base, &temp, 4);
+		break;
+	}
+}
+
+static ssize_t aspeed_smc_read_user(struct spi_nor *nor, loff_t from,
+				    size_t len, u_char *read_buf)
+{
+	struct aspeed_smc_chip *chip = nor->priv;
+
+	aspeed_smc_start_user(nor);
+	aspeed_smc_send_cmd_addr(nor, nor->read_opcode, from);
+	aspeed_smc_read_from_ahb(read_buf, chip->ahb_base, len);
+	aspeed_smc_stop_user(nor);
+	return len;
+}
+
+static ssize_t aspeed_smc_write_user(struct spi_nor *nor, loff_t to,
+				     size_t len, const u_char *write_buf)
+{
+	struct aspeed_smc_chip *chip = nor->priv;
+
+	aspeed_smc_start_user(nor);
+	aspeed_smc_send_cmd_addr(nor, nor->program_opcode, to);
+	aspeed_smc_write_to_ahb(chip->ahb_base, write_buf, len);
+	aspeed_smc_stop_user(nor);
+	return len;
+}
+
+static int aspeed_smc_unregister(struct aspeed_smc_controller *controller)
+{
+	struct aspeed_smc_chip *chip;
+	int n;
+
+	for (n = 0; n < controller->info->nce; n++) {
+		chip = controller->chips[n];
+		if (chip)
+			mtd_device_unregister(&chip->nor.mtd);
+	}
+
+	return 0;
+}
+
+static int aspeed_smc_remove(struct platform_device *dev)
+{
+	return aspeed_smc_unregister(platform_get_drvdata(dev));
+}
+
+static const struct of_device_id aspeed_smc_matches[] = {
+	{ .compatible = "aspeed,ast2500-fmc", .data = &fmc_2500_info },
+	{ .compatible = "aspeed,ast2500-spi", .data = &spi_2500_info },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, aspeed_smc_matches);
+
+/*
+ * Each chip has a mapping window defined by a segment address
+ * register defining a start and an end address on the AHB bus. These
+ * addresses can be configured to fit the chip size and offer a
+ * contiguous memory region across chips. For the moment, we only
+ * check that each chip segment is valid.
+ */
+static void __iomem *aspeed_smc_chip_base(struct aspeed_smc_chip *chip,
+					  struct resource *res)
+{
+	struct aspeed_smc_controller *controller = chip->controller;
+	u32 offset = 0;
+	u32 reg;
+
+	if (controller->info->nce > 1) {
+		reg = readl(controller->regs + SEGMENT_ADDR_REG0 +
+			    chip->cs * 4);
+
+		if (SEGMENT_ADDR_START(reg) >= SEGMENT_ADDR_END(reg))
+			return NULL;
+
+		offset = SEGMENT_ADDR_START(reg) - res->start;
+	}
+
+	return controller->ahb_base + offset;
+}
+
+static void aspeed_smc_chip_enable_write(struct aspeed_smc_chip *chip)
+{
+	struct aspeed_smc_controller *controller = chip->controller;
+	u32 reg;
+
+	reg = readl(controller->regs + CONFIG_REG);
+
+	reg |= aspeed_smc_chip_write_bit(chip);
+	writel(reg, controller->regs + CONFIG_REG);
+}
+
+static void aspeed_smc_chip_set_type(struct aspeed_smc_chip *chip, int type)
+{
+	struct aspeed_smc_controller *controller = chip->controller;
+	u32 reg;
+
+	chip->type = type;
+
+	reg = readl(controller->regs + CONFIG_REG);
+	reg &= ~(3 << (chip->cs * 2));
+	reg |= chip->type << (chip->cs * 2);
+	writel(reg, controller->regs + CONFIG_REG);
+}
+
+/*
+ * The AST2500 FMC flash controller should be strapped by hardware, or
+ * autodetected, but the AST2500 SPI flash needs to be set.
+ */
+static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip)
+{
+	struct aspeed_smc_controller *controller = chip->controller;
+	u32 reg;
+
+	if (chip->controller->info == &spi_2500_info) {
+		reg = readl(controller->regs + CE_CONTROL_REG);
+		reg |= 1 << chip->cs;
+		writel(reg, controller->regs + CE_CONTROL_REG);
+	}
+}
+
+static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
+				      struct resource *res)
+{
+	struct aspeed_smc_controller *controller = chip->controller;
+	const struct aspeed_smc_info *info = controller->info;
+	u32 reg, base_reg;
+
+	/*
+	 * Always turn on the write enable bit to allow opcodes to be
+	 * sent in user mode.
+	 */
+	aspeed_smc_chip_enable_write(chip);
+
+	/* The driver only supports SPI type flash */
+	if (info->hastype)
+		aspeed_smc_chip_set_type(chip, smc_type_spi);
+
+	/*
+	 * Configure chip base address in memory
+	 */
+	chip->ahb_base = aspeed_smc_chip_base(chip, res);
+	if (!chip->ahb_base) {
+		dev_warn(chip->nor.dev, "CE segment window closed.\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * Get value of the inherited control register. U-Boot usually
+	 * does some timing calibration on the FMC chip, so it's good
+	 * to keep them. In the future, we should handle calibration
+	 * from Linux.
+	 */
+	reg = readl(chip->ctl);
+	dev_dbg(controller->dev, "control register: %08x\n", reg);
+
+	base_reg = reg & CONTROL_KEEP_MASK;
+	if (base_reg != reg) {
+		dev_info(controller->dev,
+			 "control register changed to: %08x\n",
+			 base_reg);
+	}
+	chip->ctl_val[smc_base] = base_reg;
+
+	/*
+	 * Retain the prior value of the control register as the
+	 * default if it was normal access mode. Otherwise start with
+	 * the sanitized base value set to read mode.
+	 */
+	if ((reg & CONTROL_COMMAND_MODE_MASK) ==
+	    CONTROL_COMMAND_MODE_NORMAL)
+		chip->ctl_val[smc_read] = reg;
+	else
+		chip->ctl_val[smc_read] = chip->ctl_val[smc_base] |
+			CONTROL_COMMAND_MODE_NORMAL;
+
+	dev_dbg(controller->dev, "default control register: %08x\n",
+		chip->ctl_val[smc_read]);
+	return 0;
+}
+
+static int aspeed_smc_chip_setup_finish(struct aspeed_smc_chip *chip)
+{
+	struct aspeed_smc_controller *controller = chip->controller;
+	const struct aspeed_smc_info *info = controller->info;
+	u32 cmd;
+
+	if (chip->nor.addr_width == 4 && info->set_4b)
+		info->set_4b(chip);
+
+	/*
+	 * base mode has not been optimized yet. use it for writes.
+	 */
+	chip->ctl_val[smc_write] = chip->ctl_val[smc_base] |
+		chip->nor.program_opcode << CONTROL_COMMAND_SHIFT |
+		CONTROL_COMMAND_MODE_WRITE;
+
+	dev_dbg(controller->dev, "write control register: %08x\n",
+		chip->ctl_val[smc_write]);
+
+	/*
+	 * TODO: Adjust clocks if fast read is supported and interpret
+	 * SPI-NOR flags to adjust controller settings.
+	 */
+	switch (chip->nor.flash_read) {
+	case SPI_NOR_NORMAL:
+		cmd = CONTROL_COMMAND_MODE_NORMAL;
+		break;
+	case SPI_NOR_FAST:
+		cmd = CONTROL_COMMAND_MODE_FREAD;
+		break;
+	default:
+		dev_err(chip->nor.dev, "unsupported SPI read mode\n");
+		return -EINVAL;
+	}
+
+	chip->ctl_val[smc_read] |= cmd |
+		CONTROL_IO_DUMMY_SET(chip->nor.read_dummy / 8);
+
+	dev_dbg(controller->dev, "base control register: %08x\n",
+		chip->ctl_val[smc_read]);
+	return 0;
+}
+
+static int aspeed_smc_setup_flash(struct aspeed_smc_controller *controller,
+				  struct device_node *np, struct resource *r)
+{
+	const struct aspeed_smc_info *info = controller->info;
+	struct device *dev = controller->dev;
+	struct device_node *child;
+	unsigned int cs;
+	int ret = -ENODEV;
+
+	for_each_available_child_of_node(np, child) {
+		struct aspeed_smc_chip *chip;
+		struct spi_nor *nor;
+		struct mtd_info *mtd;
+
+		/* This driver does not support NAND or NOR flash devices. */
+		if (!of_device_is_compatible(child, "jedec,spi-nor"))
+			continue;
+
+		ret = of_property_read_u32(child, "reg", &cs);
+		if (ret) {
+			dev_err(dev, "Couldn't not read chip select.\n");
+			break;
+		}
+
+		if (cs >= info->nce) {
+			dev_err(dev, "Chip select %d out of range.\n",
+				cs);
+			ret = -ERANGE;
+			break;
+		}
+
+		if (controller->chips[cs]) {
+			dev_err(dev, "Chip select %d already in use by %s\n",
+				cs, dev_name(controller->chips[cs]->nor.dev));
+			ret = -EBUSY;
+			break;
+		}
+
+		chip = devm_kzalloc(controller->dev, sizeof(*chip), GFP_KERNEL);
+		if (!chip) {
+			ret = -ENOMEM;
+			break;
+		}
+
+		chip->controller = controller;
+		chip->ctl = controller->regs + info->ctl0 + cs * 4;
+		chip->cs = cs;
+
+		nor = &chip->nor;
+		mtd = &nor->mtd;
+
+		nor->dev = dev;
+		nor->priv = chip;
+		spi_nor_set_flash_node(nor, child);
+		nor->read = aspeed_smc_read_user;
+		nor->write = aspeed_smc_write_user;
+		nor->read_reg = aspeed_smc_read_reg;
+		nor->write_reg = aspeed_smc_write_reg;
+		nor->prepare = aspeed_smc_prep;
+		nor->unprepare = aspeed_smc_unprep;
+
+		mtd->name = of_get_property(child, "label", NULL);
+
+		ret = aspeed_smc_chip_setup_init(chip, r);
+		if (ret)
+			break;
+
+		/*
+		 * TODO: Add support for SPI_NOR_QUAD and SPI_NOR_DUAL
+		 * attach when board support is present as determined
+		 * by of property.
+		 */
+		ret = spi_nor_scan(nor, NULL, SPI_NOR_NORMAL);
+		if (ret)
+			break;
+
+		ret = aspeed_smc_chip_setup_finish(chip);
+		if (ret)
+			break;
+
+		ret = mtd_device_register(mtd, NULL, 0);
+		if (ret)
+			break;
+
+		controller->chips[cs] = chip;
+	}
+
+	if (ret)
+		aspeed_smc_unregister(controller);
+
+	return ret;
+}
+
+static int aspeed_smc_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device *dev = &pdev->dev;
+	struct aspeed_smc_controller *controller;
+	const struct of_device_id *match;
+	const struct aspeed_smc_info *info;
+	struct resource *res;
+	int ret;
+
+	match = of_match_device(aspeed_smc_matches, &pdev->dev);
+	if (!match || !match->data)
+		return -ENODEV;
+	info = match->data;
+
+	controller = devm_kzalloc(&pdev->dev, sizeof(*controller) +
+		info->nce * sizeof(controller->chips[0]), GFP_KERNEL);
+	if (!controller)
+		return -ENOMEM;
+	controller->info = info;
+	controller->dev = dev;
+
+	mutex_init(&controller->mutex);
+	platform_set_drvdata(pdev, controller);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	controller->regs = devm_ioremap_resource(dev, res);
+	if (IS_ERR(controller->regs)) {
+		dev_err(dev, "Cannot remap controller address.\n");
+		return PTR_ERR(controller->regs);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	controller->ahb_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(controller->ahb_base)) {
+		dev_err(dev, "Cannot remap controller address.\n");
+		return PTR_ERR(controller->ahb_base);
+	}
+
+	ret = aspeed_smc_setup_flash(controller, np, res);
+	if (ret)
+		dev_err(dev, "Aspeed SMC probe failed %d\n", ret);
+
+	return ret;
+}
+
+static struct platform_driver aspeed_smc_driver = {
+	.probe = aspeed_smc_probe,
+	.remove = aspeed_smc_remove,
+	.driver = {
+		.name = DEVICE_NAME,
+		.of_match_table = aspeed_smc_matches,
+	}
+};
+
+module_platform_driver(aspeed_smc_driver);
+
+MODULE_DESCRIPTION("ASPEED Static Memory Controller Driver");
+MODULE_AUTHOR("Cedric Le Goater <clg@kaod.org>");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox