* Re: [PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20
From: Laurent Pinchart @ 2016-11-11 13:49 UTC (permalink / raw)
To: Hans Verkuil
Cc: Ramesh Shanmugasundaram, robh+dt, mark.rutland, mchehab,
sakari.ailus, crope, chris.paterson2, geert+renesas, linux-media,
devicetree, linux-renesas-soc
In-Reply-To: <502a606c-2d66-4257-af17-7b7f35f2c839@xs4all.nl>
Hi Hans,
On Friday 11 Nov 2016 14:24:41 Hans Verkuil wrote:
> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
> > This patch adds support for the three new SDR formats. These formats
> > were prefixed with "sliced" indicating I data constitutes the top half and
> > Q data constitutes the bottom half of the received buffer.
>
> The standard terminology for video formats is "planar". I am leaning towards
> using that here as well.
Another important question is whether we should introduce an SDR planar API.
That's what we would like your opinion on.
> > V4L2_SDR_FMT_SCU16BE - 14-bit complex (I & Q) unsigned big-endian sample
> > inside 16-bit. V4L2 FourCC: SC16
> >
> > V4L2_SDR_FMT_SCU18BE - 16-bit complex (I & Q) unsigned big-endian sample
> > inside 18-bit. V4L2 FourCC: SC18
> >
> > V4L2_SDR_FMT_SCU20BE - 18-bit complex (I & Q) unsigned big-endian sample
> > inside 20-bit. V4L2 FourCC: SC20
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > <ramesh.shanmugasundaram@bp.renesas.com> ---
> >
> > drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
> > include/uapi/linux/videodev2.h | 3 +++
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c index 181381d..d36b386 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1207,6 +1207,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
> > *fmt)>
> > case V4L2_SDR_FMT_CS8: descr = "Complex S8"; break;
> > case V4L2_SDR_FMT_CS14LE: descr = "Complex S14LE"; break;
> > case V4L2_SDR_FMT_RU12LE: descr = "Real U12LE"; break;
> >
> > + case V4L2_SDR_FMT_SCU16BE: descr = "Sliced Complex U16BE"; break;
> > + case V4L2_SDR_FMT_SCU18BE: descr = "Sliced Complex U18BE"; break;
> > + case V4L2_SDR_FMT_SCU20BE: descr = "Sliced Complex U20BE"; break;
> >
> > case V4L2_TCH_FMT_DELTA_TD16: descr = "16-bit signed deltas"; break;
> > case V4L2_TCH_FMT_DELTA_TD08: descr = "8-bit signed deltas"; break;
> > case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data";
break;
> >
> > diff --git a/include/uapi/linux/videodev2.h
> > b/include/uapi/linux/videodev2.h index 4364ce6..34a9c30 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -666,6 +666,9 @@ struct v4l2_pix_format {
> >
> > #define V4L2_SDR_FMT_CS8 v4l2_fourcc('C', 'S', '0', '8') /*
> > complex s8 */ #define V4L2_SDR_FMT_CS14LE v4l2_fourcc('C', 'S',
> > '1', '4') /* complex s14le */ #define V4L2_SDR_FMT_RU12LE
> > v4l2_fourcc('R', 'U', '1', '2') /* real u12le */>
> > +#define V4L2_SDR_FMT_SCU16BE v4l2_fourcc('S', 'C', '1', '6') /*
sliced
> > complex u16be */ +#define V4L2_SDR_FMT_SCU18BE v4l2_fourcc('S',
'C',
> > '1', '8') /* sliced complex u18be */ +#define V4L2_SDR_FMT_SCU20BE
> > v4l2_fourcc('S', 'C', '2', '0') /* sliced complex u20be */>
> > /* Touch formats - used for Touch devices */
> > #define V4L2_TCH_FMT_DELTA_TD16 v4l2_fourcc('T', 'D', '1', '6') /* 16-
bit
> > signed deltas */
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
From: Hans Verkuil @ 2016-11-11 13:53 UTC (permalink / raw)
To: Laurent Pinchart, Ramesh Shanmugasundaram
Cc: Antti Palosaari, robh+dt@kernel.org, mark.rutland@arm.com,
mchehab@kernel.org, sakari.ailus@linux.intel.com, Chris Paterson,
geert@linux-m68k.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <1805711.Tm0TqcXx1h@avalon>
On 11/10/2016 09:08 AM, Laurent Pinchart wrote:
> Antti, Hans, ping ? Please see below.
>
> On Friday 04 Nov 2016 09:23:29 Ramesh Shanmugasundaram wrote:
>>> On 11/02/2016 10:58 PM, Laurent Pinchart wrote:
>>>> On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
>>>>>>> On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
>>>>>>>
>>>>>>>> This patch adds documentation for the three new SDR formats
>>>>>>>>
>>>>>>>> V4L2_SDR_FMT_SCU16BE
>>>>>>>> V4L2_SDR_FMT_SCU18BE
>>>>>>>> V4L2_SDR_FMT_SCU20BE
>>>>>
>>>>> [snip]
>>>>>
>>>>>>>> +
>>>>>>>> + - start + 0:
>>>>>>>> +
>>>>>>>> + - I'\ :sub:`0[D13:D6]`
>>>>>>>> +
>>>>>>>> + - I'\ :sub:`0[D5:D0]`
>>>>>>>> +
>>>>>>>> + - .. row 2
>>>>>>>> +
>>>>>>>> + - start + buffer_size/2:
>>>>>>>> +
>>>>>>>> + - Q'\ :sub:`0[D13:D6]`
>>>>>>>> +
>>>>>>>> + - Q'\ :sub:`0[D5:D0]`
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The format looks planar, does it use one V4L2 plane (as does NV12)
>>>>>>> or two V4L2 planes (as does NV12M) ? Same question for the other
>>>>>>> formats.
>>>>>>
>>>>>> Thank you for bringing up this topic. This is one of the key design
>>>>>> dilemma.
>>>>>>
>>>>>> The I & Q data for these three SDR formats comes from two different
>>>>>> DMA channels and hence two separate pointers -> we could say it is
>>>>>> v4l2 multi- planar. Right now, I am making it look like a single
>>>>>> plane by presenting the data in one single buffer ptr.
>>>>>>
>>>>>> For e.g. multi-planar SC16 format would look something like this
>>>>>>
>>>>>> <------------------------32bits---------------------->
>>>>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 0
>>>>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 4
>>>>>> ...
>>>>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 0
>>>>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 4
>>>>>>
>>>>>> My concerns are
>>>>>>
>>>>>> 1) These formats are not a standard as the video "Image Formats".
>>>>>> These formats are possible when we use DRIF + MAX2175 combination.
>>>>>> If we interface with a different tuner vendor, the above format(s)
>>>>>> MAY/MAY NOT be re-usable. We do not know at this point. This is the
>>>>>> main open item for discussion in the cover letter.
>>>>
>>>> If the formats are really device-specific then they should be
>>>> documented accordingly and not made generic.
>>>>
>>>>>> 2) MPLANE support within V4L2 seems specific to video. Please
>>>>>> correct me if this is wrong interpretation.
>>>>>>
>>>>>> - struct v4l2_format contains v4l2_sdr_format and
>>>>>> v4l2_pix_format_mplane as members of union. Should I create a new
>>>>>> v4l2_sdr_format_mplane? If I have to use v4l2_pix_format_mplane most
>>>>>> of the video specific members would be unused (it would be similar
>>>>>> to using v4l2_pix_format itself instead of v4l2_sdr_format)?
>>>>
>>>> I have no answer to that question as I'm not familiar with SDR. Antti,
>>>> you've added v4l2_sdr_format to the API, what's your opinion ? Hans,
>>>> as you've acked the patch, your input would be appreciated as well.
>>>
>>> If I understood correctly this hardware provides I and Q samples via
>>> different channels and driver now combines those channels as a sequential
>>> IQ sample pairs.
>>
>> The driver combines the two buffer ptrs and present as one single buffer.
>> For a buffer of size 200
>>
>> ptr + 0 : I I I I ... I
>> ptr + 100 : Q Q Q Q ... Q
>>
>>> I have never seen any other than hw which provides IQ IQ IQ IQ ... IQ.
>>
>> There are some modes where this h/w combo can also do IQ IQ IQ pattern.
>> Those modes are not added in the RFC patchset.
>>
>>> This is
>>> I I I I ... I
>>> Q Q Q Q ... Q
>>> I am not very familiar with planars, but it sounds like it is correct
>>> approach. So I think should be added rather than emulate packet
>>> sequential format.
>>
>> My understanding of V4L2 MPLANE constructs is limited to a quick code read
>> only. At this point MPLANE support seems specific to video. SDR is defined
>> as separate format like v4l2_pix_format. Questions would be - should we
>> define new SDR_MPLANE? or merge SDR format with pix format & reuse existing
>> MPLANE with some SDR extensions (if possible)? These seem big design
>> decisions. Any suggestions please?
>>
>> For my use case, MPLANE support does not seem to add significant benefit
>> except it may be syntactically correct. I am doing cyclic DMA with a small
>> set of h/w buffers and copying each stage to one mmapped vmalloc vb2_buffer
>> at two offsets. If we add MPLANE support, it can be two non-contiguous
>> buffer pointers.
>>
>>>>>> - The above decision (accomodate SDR & MPLANE) needs to be
>>>>>> propagated across the framework. Is this the preferred approach?
>>>>>>
>>>>>> It goes back to point (1). As of today, the change set for this
>>>>>> combo (DRIF+MAX2175) introduces new SDR formats only. Should it add
>>>>>> further SDR+MPLANE support to the framework as well?
>>>>>>
>>>>>> I would appreciate your suggestions on this regard.
>
Some terminology first:
Planar formats separate the data into different memory areas: in this case
one part is all I and one part is all Q. This as opposed to interleaved
formats (IQIQIQIQ....).
As long as both planes fit in the same buffer all is fine. Since that is
the case here there is no need to introduce a new MPLANE API.
The MPLANE API was added for video to handle cases where the two planes
had to be in two different non-contiguous buffers.
So instead of passing one buffer pointer, you need to pass two or more
buffer pointers.
In hindsight we should have called it the MBUFFER API.
Oh well...
Anyway, since there is no problem here apparently to keep both planes
in one buffer there is also no need to introduce a SDR_MPLANE.
Regards,
Hans
^ permalink raw reply
* Re: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
From: Laurent Pinchart @ 2016-11-11 13:57 UTC (permalink / raw)
To: Hans Verkuil
Cc: Ramesh Shanmugasundaram, Antti Palosaari,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
Chris Paterson, geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <8438b944-216e-3237-c312-92a674fd4541-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Hi Hans,
On Friday 11 Nov 2016 14:53:58 Hans Verkuil wrote:
> On 11/10/2016 09:08 AM, Laurent Pinchart wrote:
> > Antti, Hans, ping ? Please see below.
> >
> > On Friday 04 Nov 2016 09:23:29 Ramesh Shanmugasundaram wrote:
> >>> On 11/02/2016 10:58 PM, Laurent Pinchart wrote:
> >>>> On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
> >>>>>>> On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
> >>>>>>>> This patch adds documentation for the three new SDR formats
> >>>>>>>>
> >>>>>>>> V4L2_SDR_FMT_SCU16BE
> >>>>>>>> V4L2_SDR_FMT_SCU18BE
> >>>>>>>> V4L2_SDR_FMT_SCU20BE
> >>>>>
> >>>>> [snip]
> >>>>>
> >>>>>>>> +
> >>>>>>>> + - start + 0:
> >>>>>>>> +
> >>>>>>>> + - I'\ :sub:`0[D13:D6]`
> >>>>>>>> +
> >>>>>>>> + - I'\ :sub:`0[D5:D0]`
> >>>>>>>> +
> >>>>>>>> + - .. row 2
> >>>>>>>> +
> >>>>>>>> + - start + buffer_size/2:
> >>>>>>>> +
> >>>>>>>> + - Q'\ :sub:`0[D13:D6]`
> >>>>>>>> +
> >>>>>>>> + - Q'\ :sub:`0[D5:D0]`
> >>>>>>>
> >>>>>>> The format looks planar, does it use one V4L2 plane (as does NV12)
> >>>>>>> or two V4L2 planes (as does NV12M) ? Same question for the other
> >>>>>>> formats.
> >>>>>>
> >>>>>> Thank you for bringing up this topic. This is one of the key design
> >>>>>> dilemma.
> >>>>>>
> >>>>>> The I & Q data for these three SDR formats comes from two different
> >>>>>> DMA channels and hence two separate pointers -> we could say it is
> >>>>>> v4l2 multi- planar. Right now, I am making it look like a single
> >>>>>> plane by presenting the data in one single buffer ptr.
> >>>>>>
> >>>>>> For e.g. multi-planar SC16 format would look something like this
> >>>>>>
> >>>>>> <------------------------32bits---------------------->
> >>>>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 0
> >>>>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 4
> >>>>>> ...
> >>>>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 0
> >>>>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 4
> >>>>>>
> >>>>>> My concerns are
> >>>>>>
> >>>>>> 1) These formats are not a standard as the video "Image Formats".
> >>>>>> These formats are possible when we use DRIF + MAX2175 combination.
> >>>>>> If we interface with a different tuner vendor, the above format(s)
> >>>>>> MAY/MAY NOT be re-usable. We do not know at this point. This is the
> >>>>>> main open item for discussion in the cover letter.
> >>>>
> >>>> If the formats are really device-specific then they should be
> >>>> documented accordingly and not made generic.
> >>>>
> >>>>>> 2) MPLANE support within V4L2 seems specific to video. Please
> >>>>>> correct me if this is wrong interpretation.
> >>>>>>
> >>>>>> - struct v4l2_format contains v4l2_sdr_format and
> >>>>>> v4l2_pix_format_mplane as members of union. Should I create a new
> >>>>>> v4l2_sdr_format_mplane? If I have to use v4l2_pix_format_mplane most
> >>>>>> of the video specific members would be unused (it would be similar
> >>>>>> to using v4l2_pix_format itself instead of v4l2_sdr_format)?
> >>>>
> >>>> I have no answer to that question as I'm not familiar with SDR. Antti,
> >>>> you've added v4l2_sdr_format to the API, what's your opinion ? Hans,
> >>>> as you've acked the patch, your input would be appreciated as well.
> >>>
> >>> If I understood correctly this hardware provides I and Q samples via
> >>> different channels and driver now combines those channels as a
> >>> sequential
> >>> IQ sample pairs.
> >>
> >> The driver combines the two buffer ptrs and present as one single buffer.
> >> For a buffer of size 200
> >>
> >> ptr + 0 : I I I I ... I
> >> ptr + 100 : Q Q Q Q ... Q
> >>
> >>> I have never seen any other than hw which provides IQ IQ IQ IQ ... IQ.
> >>
> >> There are some modes where this h/w combo can also do IQ IQ IQ pattern.
> >> Those modes are not added in the RFC patchset.
> >>
> >>> This is
> >>> I I I I ... I
> >>> Q Q Q Q ... Q
> >>> I am not very familiar with planars, but it sounds like it is correct
> >>> approach. So I think should be added rather than emulate packet
> >>> sequential format.
> >>
> >> My understanding of V4L2 MPLANE constructs is limited to a quick code
> >> read
> >> only. At this point MPLANE support seems specific to video. SDR is
> >> defined
> >> as separate format like v4l2_pix_format. Questions would be - should we
> >> define new SDR_MPLANE? or merge SDR format with pix format & reuse
> >> existing
> >> MPLANE with some SDR extensions (if possible)? These seem big design
> >> decisions. Any suggestions please?
> >>
> >> For my use case, MPLANE support does not seem to add significant benefit
> >> except it may be syntactically correct. I am doing cyclic DMA with a
> >> small
> >> set of h/w buffers and copying each stage to one mmapped vmalloc
> >> vb2_buffer
> >> at two offsets. If we add MPLANE support, it can be two non-contiguous
> >> buffer pointers.
> >>
> >>>>>> - The above decision (accomodate SDR & MPLANE) needs to be
> >>>>>> propagated across the framework. Is this the preferred approach?
> >>>>>>
> >>>>>> It goes back to point (1). As of today, the change set for this
> >>>>>> combo (DRIF+MAX2175) introduces new SDR formats only. Should it add
> >>>>>> further SDR+MPLANE support to the framework as well?
> >>>>>>
> >>>>>> I would appreciate your suggestions on this regard.
>
> Some terminology first:
>
> Planar formats separate the data into different memory areas: in this case
> one part is all I and one part is all Q. This as opposed to interleaved
> formats (IQIQIQIQ....).
>
> As long as both planes fit in the same buffer all is fine. Since that is
> the case here there is no need to introduce a new MPLANE API.
>
> The MPLANE API was added for video to handle cases where the two planes
> had to be in two different non-contiguous buffers.
Not only that, it can also be used for cases where storing the two planes in
separate buffers can be beneficial, even if a single contiguous buffer could
work.
> So instead of passing one buffer pointer, you need to pass two or more
> buffer pointers.
>
> In hindsight we should have called it the MBUFFER API.
The name was badly chosen, yes.
> Oh well...
>
> Anyway, since there is no problem here apparently to keep both planes
> in one buffer there is also no need to introduce a SDR_MPLANE.
The question here is whether there could be a benefit in separating I and Q
data in two buffers compared to storing them in the same buffer.
--
Regards,
Laurent Pinchart
--
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 2/5] media: i2c: max2175: Add MAX2175 support
From: Hans Verkuil @ 2016-11-11 13:58 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ramesh Shanmugasundaram, robh+dt, mark.rutland, mchehab,
sakari.ailus, crope, chris.paterson2, geert+renesas, linux-media,
devicetree, linux-renesas-soc
In-Reply-To: <1903855.3Xg5AI8ucK@avalon>
On 11/11/2016 02:48 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Friday 11 Nov 2016 14:21:22 Hans Verkuil wrote:
>> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
>>> This patch adds driver support for MAX2175 chip. This is Maxim
>>> Integrated's RF to Bits tuner front end chip designed for software-defined
>>> radio solutions. This driver exposes the tuner as a sub-device instance
>>> with standard and custom controls to configure the device.
>>>
>>> Signed-off-by: Ramesh Shanmugasundaram
>>> <ramesh.shanmugasundaram@bp.renesas.com> ---
>>>
>>> .../devicetree/bindings/media/i2c/max2175.txt | 61 +
>>> drivers/media/i2c/Kconfig | 4 +
>>> drivers/media/i2c/Makefile | 2 +
>>> drivers/media/i2c/max2175/Kconfig | 8 +
>>> drivers/media/i2c/max2175/Makefile | 4 +
>>> drivers/media/i2c/max2175/max2175.c | 1558 +++++++++++++++
>>> drivers/media/i2c/max2175/max2175.h | 108 ++
>>> 7 files changed, 1745 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/media/i2c/max2175.txt
>>> create mode 100644 drivers/media/i2c/max2175/Kconfig
>>> create mode 100644 drivers/media/i2c/max2175/Makefile
>>> create mode 100644 drivers/media/i2c/max2175/max2175.c
>>> create mode 100644 drivers/media/i2c/max2175/max2175.h
>>
>> <snip>
>>
>>> diff --git a/drivers/media/i2c/max2175/max2175.c
>>> b/drivers/media/i2c/max2175/max2175.c new file mode 100644
>>> index 0000000..ec45b52
>>> --- /dev/null
>>> +++ b/drivers/media/i2c/max2175/max2175.c
>>> @@ -0,0 +1,1558 @@
>>
>> <snip>
>>
>>> +/* Read/Write bit(s) on top of regmap */
>>> +static int max2175_read(struct max2175 *ctx, u8 idx, u8 *val)
>>> +{
>>> + u32 regval;
>>> + int ret = regmap_read(ctx->regmap, idx, ®val);
>>> +
>>> + if (ret)
>>> + v4l2_err(ctx->client, "read ret(%d): idx 0x%02x\n", ret, idx);
>
> By the way, I think I've seen a proposal to get rid of v4l2_err() in favour of
> dev_err(), was I dreaming or should this patch use dev_err() already ?
I haven't seen anything, but I may have missed it. I haven't been on top of the
mailinglist lately. I'm fine with both.
>
>>> +
>>> + *val = regval;
>>
>> Does regmap_read initialize regval even if it returns an error? If not,
>> then I would initialize regval to 0 to prevent *val being uninitialized.
>
> Better than that the error should be propagated to the caller and handled.
>
>>> + return ret;
>>> +}
>
> [snip]
>
>>> +static int max2175_band_from_freq(u32 freq)
>>> +{
>>> + if (freq >= 144000 && freq <= 26100000)
>>> + return MAX2175_BAND_AM;
>>> + else if (freq >= 65000000 && freq <= 108000000)
>>> + return MAX2175_BAND_FM;
>>> + else
>>
>> No need for these 'else' keywords.
>
> Indeed by in my opinion they improve readability :-)
>
>>> + return MAX2175_BAND_VHF;
>>> +}
>
> [snip]
>
>>> +static const struct v4l2_ctrl_config max2175_na_rx_mode = {
>>> + .ops = &max2175_ctrl_ops,
>>> + .id = V4L2_CID_MAX2175_RX_MODE,
>>> + .name = "RX MODE",
>>> + .type = V4L2_CTRL_TYPE_MENU,
>>> + .max = ARRAY_SIZE(max2175_ctrl_na_rx_modes) - 1,
>>> + .def = 0,
>>> + .qmenu = max2175_ctrl_na_rx_modes,
>>> +};
>>
>> Please document all these controls better. This is part of the public API,
>> so you need to give more information what this means exactly.
>
> Should that go to Documentation/media/v4l-drivers/ ? If so "[PATCH v4 3/4]
> v4l: Add Renesas R-Car FDP1 Driver" can be used as an example.
I think that's the preferred place going forward. But a comment should be
added here pointing to that file so there is a better chance of keeping
the doc and code in sync.
>
> [snip]
>
Hans
^ permalink raw reply
* [PATCH 1/3] powerpc/fsl/dts: add QMan and BMan portal nodes on t1023rdb
From: Madalin Bucur @ 2016-11-11 13:59 UTC (permalink / raw)
To: devicetree; +Cc: oss, linuxppc-dev
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/boot/dts/fsl/t1023rdb.dts | 27 ++++++++
arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 103 ++++++++++++++++++++++++++++
2 files changed, 130 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1023rdb.dts b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
index 2975762..24c9de3 100644
--- a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
@@ -41,6 +41,25 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ };
+ qman_fqd: qman-fqd {
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ };
+ qman_pfdr: qman-pfdr {
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ };
+ };
+
ifc: localbus@ffe124000 {
reg = <0xf 0xfe124000 0 0x2000>;
ranges = <0 0 0xf 0xe8000000 0x08000000
@@ -72,6 +91,14 @@
ranges = <0x00000000 0xf 0x00000000 0x01072000>;
};
+ bportals: bman-portals@ff4000000 {
+ ranges = <0x0 0xf 0xf4000000 0x2000000>;
+ };
+
+ qportals: qman-portals@ff6000000 {
+ ranges = <0x0 0xf 0xf6000000 0x2000000>;
+ };
+
soc: soc@ffe000000 {
ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
reg = <0xf 0xfe000000 0 0x00001000>;
diff --git a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
index 6e0b489..da2894c 100644
--- a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
@@ -34,6 +34,21 @@
#include <dt-bindings/thermal/thermal.h>
+&bman_fbpr {
+ compatible = "fsl,bman-fbpr";
+ alloc-ranges = <0 0 0x10000 0>;
+};
+
+&qman_fqd {
+ compatible = "fsl,qman-fqd";
+ alloc-ranges = <0 0 0x10000 0>;
+};
+
+&qman_pfdr {
+ compatible = "fsl,qman-pfdr";
+ alloc-ranges = <0 0 0x10000 0>;
+};
+
&ifc {
#address-cells = <2>;
#size-cells = <1>;
@@ -180,6 +195,92 @@
};
};
+&bportals {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "simple-bus";
+
+ bman-portal@0 {
+ cell-index = <0x0>;
+ compatible = "fsl,bman-portal";
+ reg = <0x0 0x4000>, <0x1000000 0x1000>;
+ interrupts = <105 2 0 0>;
+ };
+ bman-portal@4000 {
+ cell-index = <0x1>;
+ compatible = "fsl,bman-portal";
+ reg = <0x4000 0x4000>, <0x1001000 0x1000>;
+ interrupts = <107 2 0 0>;
+ };
+ bman-portal@8000 {
+ cell-index = <2>;
+ compatible = "fsl,bman-portal";
+ reg = <0x8000 0x4000>, <0x1002000 0x1000>;
+ interrupts = <109 2 0 0>;
+ };
+ bman-portal@c000 {
+ cell-index = <0x3>;
+ compatible = "fsl,bman-portal";
+ reg = <0xc000 0x4000>, <0x1003000 0x1000>;
+ interrupts = <111 2 0 0>;
+ };
+ bman-portal@10000 {
+ cell-index = <0x4>;
+ compatible = "fsl,bman-portal";
+ reg = <0x10000 0x4000>, <0x1004000 0x1000>;
+ interrupts = <113 2 0 0>;
+ };
+ bman-portal@14000 {
+ cell-index = <0x5>;
+ compatible = "fsl,bman-portal";
+ reg = <0x14000 0x4000>, <0x1005000 0x1000>;
+ interrupts = <115 2 0 0>;
+ };
+};
+
+&qportals {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "simple-bus";
+
+ qportal0: qman-portal@0 {
+ compatible = "fsl,qman-portal";
+ reg = <0x0 0x4000>, <0x1000000 0x1000>;
+ interrupts = <104 0x2 0 0>;
+ cell-index = <0x0>;
+ };
+ qportal1: qman-portal@4000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x4000 0x4000>, <0x1001000 0x1000>;
+ interrupts = <106 0x2 0 0>;
+ cell-index = <0x1>;
+ };
+ qportal2: qman-portal@8000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x8000 0x4000>, <0x1002000 0x1000>;
+ interrupts = <108 0x2 0 0>;
+ cell-index = <0x2>;
+ };
+ qportal3: qman-portal@c000 {
+ compatible = "fsl,qman-portal";
+ reg = <0xc000 0x4000>, <0x1003000 0x1000>;
+ interrupts = <110 0x2 0 0>;
+ cell-index = <0x3>;
+ };
+ qportal4: qman-portal@10000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x10000 0x4000>, <0x1004000 0x1000>;
+ interrupts = <112 0x2 0 0>;
+ cell-index = <0x4>;
+ };
+ qportal5: qman-portal@14000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x14000 0x4000>, <0x1005000 0x1000>;
+ interrupts = <114 0x2 0 0>;
+ cell-index = <0x5>;
+ };
+};
+
&soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -413,6 +514,8 @@
};
/include/ "qoriq-sec5.0-0.dtsi"
+/include/ "qoriq-qman3.dtsi"
+/include/ "qoriq-bman1.dtsi"
/include/ "qoriq-fman3l-0.dtsi"
/include/ "qoriq-fman3-0-10g-0-best-effort.dtsi"
--
2.1.0
^ permalink raw reply related
* [PATCH 2/3] powerpc/fsl/dts: add QMan and BMan portal nodes on t1024
From: Madalin Bucur @ 2016-11-11 13:59 UTC (permalink / raw)
To: devicetree; +Cc: oss, linuxppc-dev
In-Reply-To: <1478872784-630-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/boot/dts/fsl/t1024qds.dts | 27 +++++++++++++++++++++++++++
arch/powerpc/boot/dts/fsl/t1024rdb.dts | 31 +++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1024qds.dts b/arch/powerpc/boot/dts/fsl/t1024qds.dts
index 772143d..339517e 100644
--- a/arch/powerpc/boot/dts/fsl/t1024qds.dts
+++ b/arch/powerpc/boot/dts/fsl/t1024qds.dts
@@ -41,6 +41,25 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ };
+ qman_fqd: qman-fqd {
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ };
+ qman_pfdr: qman-pfdr {
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ };
+ };
+
ifc: localbus@ffe124000 {
reg = <0xf 0xfe124000 0 0x2000>;
ranges = <0 0 0xf 0xe8000000 0x08000000
@@ -80,6 +99,14 @@
ranges = <0x00000000 0xf 0x00000000 0x01072000>;
};
+ bportals: bman-portals@ff4000000 {
+ ranges = <0x0 0xf 0xf4000000 0x2000000>;
+ };
+
+ qportals: qman-portals@ff6000000 {
+ ranges = <0x0 0xf 0xf6000000 0x2000000>;
+ };
+
soc: soc@ffe000000 {
ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
reg = <0xf 0xfe000000 0 0x00001000>;
diff --git a/arch/powerpc/boot/dts/fsl/t1024rdb.dts b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
index 302cdd2..2656095 100644
--- a/arch/powerpc/boot/dts/fsl/t1024rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
@@ -41,6 +41,29 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
+ aliases {
+ sg_2500_aqr105_phy4 = &sg_2500_aqr105_phy4;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ };
+ qman_fqd: qman-fqd {
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ };
+ qman_pfdr: qman-pfdr {
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ };
+ };
+
ifc: localbus@ffe124000 {
reg = <0xf 0xfe124000 0 0x2000>;
ranges = <0 0 0xf 0xe8000000 0x08000000
@@ -82,6 +105,14 @@
ranges = <0x00000000 0xf 0x00000000 0x01072000>;
};
+ bportals: bman-portals@ff4000000 {
+ ranges = <0x0 0xf 0xf4000000 0x2000000>;
+ };
+
+ qportals: qman-portals@ff6000000 {
+ ranges = <0x0 0xf 0xf6000000 0x2000000>;
+ };
+
soc: soc@ffe000000 {
ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
reg = <0xf 0xfe000000 0 0x00001000>;
--
2.1.0
^ permalink raw reply related
* [PATCH 3/3] powerpc/fsl/dts: add FMan node for t1042d4rdb
From: Madalin Bucur @ 2016-11-11 13:59 UTC (permalink / raw)
To: devicetree; +Cc: oss, linuxppc-dev
In-Reply-To: <1478872784-630-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/boot/dts/fsl/t1042d4rdb.dts | 47 ++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts b/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts
index 2a5a90d..8c0c318 100644
--- a/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts
@@ -48,6 +48,53 @@
"fsl,deepsleep-cpld";
};
};
+ soc: soc@ffe000000 {
+ fman0: fman@400000 {
+ ethernet@e0000 {
+ phy-handle = <&phy_sgmii_0>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@e2000 {
+ phy-handle = <&phy_sgmii_1>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@e4000 {
+ phy-handle = <&phy_sgmii_2>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@e6000 {
+ phy-handle = <&phy_rgmii_0>;
+ phy-connection-type = "rgmii";
+ };
+
+ ethernet@e8000 {
+ phy-handle = <&phy_rgmii_1>;
+ phy-connection-type = "rgmii";
+ };
+
+ mdio0: mdio@fc000 {
+ phy_sgmii_0: ethernet-phy@02 {
+ reg = <0x02>;
+ };
+ phy_sgmii_1: ethernet-phy@03 {
+ reg = <0x03>;
+ };
+ phy_sgmii_2: ethernet-phy@01 {
+ reg = <0x01>;
+ };
+ phy_rgmii_0: ethernet-phy@04 {
+ reg = <0x04>;
+ };
+ phy_rgmii_1: ethernet-phy@05 {
+ reg = <0x05>;
+ };
+ };
+ };
+ };
+
};
#include "t1042si-post.dtsi"
--
2.1.0
^ permalink raw reply related
* Re: [RFC 5/5] doc_rst: media: New SDR formats SC16, SC18 & SC20
From: Hans Verkuil @ 2016-11-11 14:00 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ramesh Shanmugasundaram, Antti Palosaari, robh+dt@kernel.org,
mark.rutland@arm.com, mchehab@kernel.org,
sakari.ailus@linux.intel.com, Chris Paterson,
geert@linux-m68k.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <1980094.XQVzRRgZQ8@avalon>
On 11/11/2016 02:57 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Friday 11 Nov 2016 14:53:58 Hans Verkuil wrote:
>> On 11/10/2016 09:08 AM, Laurent Pinchart wrote:
>>> Antti, Hans, ping ? Please see below.
>>>
>>> On Friday 04 Nov 2016 09:23:29 Ramesh Shanmugasundaram wrote:
>>>>> On 11/02/2016 10:58 PM, Laurent Pinchart wrote:
>>>>>> On Wednesday 02 Nov 2016 09:00:00 Ramesh Shanmugasundaram wrote:
>>>>>>>>> On Wednesday 12 Oct 2016 15:10:29 Ramesh Shanmugasundaram wrote:
>>>>>>>>>> This patch adds documentation for the three new SDR formats
>>>>>>>>>>
>>>>>>>>>> V4L2_SDR_FMT_SCU16BE
>>>>>>>>>> V4L2_SDR_FMT_SCU18BE
>>>>>>>>>> V4L2_SDR_FMT_SCU20BE
>>>>>>>
>>>>>>> [snip]
>>>>>>>
>>>>>>>>>> +
>>>>>>>>>> + - start + 0:
>>>>>>>>>> +
>>>>>>>>>> + - I'\ :sub:`0[D13:D6]`
>>>>>>>>>> +
>>>>>>>>>> + - I'\ :sub:`0[D5:D0]`
>>>>>>>>>> +
>>>>>>>>>> + - .. row 2
>>>>>>>>>> +
>>>>>>>>>> + - start + buffer_size/2:
>>>>>>>>>> +
>>>>>>>>>> + - Q'\ :sub:`0[D13:D6]`
>>>>>>>>>> +
>>>>>>>>>> + - Q'\ :sub:`0[D5:D0]`
>>>>>>>>>
>>>>>>>>> The format looks planar, does it use one V4L2 plane (as does NV12)
>>>>>>>>> or two V4L2 planes (as does NV12M) ? Same question for the other
>>>>>>>>> formats.
>>>>>>>>
>>>>>>>> Thank you for bringing up this topic. This is one of the key design
>>>>>>>> dilemma.
>>>>>>>>
>>>>>>>> The I & Q data for these three SDR formats comes from two different
>>>>>>>> DMA channels and hence two separate pointers -> we could say it is
>>>>>>>> v4l2 multi- planar. Right now, I am making it look like a single
>>>>>>>> plane by presenting the data in one single buffer ptr.
>>>>>>>>
>>>>>>>> For e.g. multi-planar SC16 format would look something like this
>>>>>>>>
>>>>>>>> <------------------------32bits---------------------->
>>>>>>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 0
>>>>>>>> <--I(14 bit data) + 2bit status--16bit padded zeros--> : start0 + 4
>>>>>>>> ...
>>>>>>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 0
>>>>>>>> <--Q(14 bit data) + 2bit status--16bit padded zeros--> : start1 + 4
>>>>>>>>
>>>>>>>> My concerns are
>>>>>>>>
>>>>>>>> 1) These formats are not a standard as the video "Image Formats".
>>>>>>>> These formats are possible when we use DRIF + MAX2175 combination.
>>>>>>>> If we interface with a different tuner vendor, the above format(s)
>>>>>>>> MAY/MAY NOT be re-usable. We do not know at this point. This is the
>>>>>>>> main open item for discussion in the cover letter.
>>>>>>
>>>>>> If the formats are really device-specific then they should be
>>>>>> documented accordingly and not made generic.
>>>>>>
>>>>>>>> 2) MPLANE support within V4L2 seems specific to video. Please
>>>>>>>> correct me if this is wrong interpretation.
>>>>>>>>
>>>>>>>> - struct v4l2_format contains v4l2_sdr_format and
>>>>>>>> v4l2_pix_format_mplane as members of union. Should I create a new
>>>>>>>> v4l2_sdr_format_mplane? If I have to use v4l2_pix_format_mplane most
>>>>>>>> of the video specific members would be unused (it would be similar
>>>>>>>> to using v4l2_pix_format itself instead of v4l2_sdr_format)?
>>>>>>
>>>>>> I have no answer to that question as I'm not familiar with SDR. Antti,
>>>>>> you've added v4l2_sdr_format to the API, what's your opinion ? Hans,
>>>>>> as you've acked the patch, your input would be appreciated as well.
>>>>>
>>>>> If I understood correctly this hardware provides I and Q samples via
>>>>> different channels and driver now combines those channels as a
>>>>> sequential
>>>>> IQ sample pairs.
>>>>
>>>> The driver combines the two buffer ptrs and present as one single buffer.
>>>> For a buffer of size 200
>>>>
>>>> ptr + 0 : I I I I ... I
>>>> ptr + 100 : Q Q Q Q ... Q
>>>>
>>>>> I have never seen any other than hw which provides IQ IQ IQ IQ ... IQ.
>>>>
>>>> There are some modes where this h/w combo can also do IQ IQ IQ pattern.
>>>> Those modes are not added in the RFC patchset.
>>>>
>>>>> This is
>>>>> I I I I ... I
>>>>> Q Q Q Q ... Q
>>>>> I am not very familiar with planars, but it sounds like it is correct
>>>>> approach. So I think should be added rather than emulate packet
>>>>> sequential format.
>>>>
>>>> My understanding of V4L2 MPLANE constructs is limited to a quick code
>>>> read
>>>> only. At this point MPLANE support seems specific to video. SDR is
>>>> defined
>>>> as separate format like v4l2_pix_format. Questions would be - should we
>>>> define new SDR_MPLANE? or merge SDR format with pix format & reuse
>>>> existing
>>>> MPLANE with some SDR extensions (if possible)? These seem big design
>>>> decisions. Any suggestions please?
>>>>
>>>> For my use case, MPLANE support does not seem to add significant benefit
>>>> except it may be syntactically correct. I am doing cyclic DMA with a
>>>> small
>>>> set of h/w buffers and copying each stage to one mmapped vmalloc
>>>> vb2_buffer
>>>> at two offsets. If we add MPLANE support, it can be two non-contiguous
>>>> buffer pointers.
>>>>
>>>>>>>> - The above decision (accomodate SDR & MPLANE) needs to be
>>>>>>>> propagated across the framework. Is this the preferred approach?
>>>>>>>>
>>>>>>>> It goes back to point (1). As of today, the change set for this
>>>>>>>> combo (DRIF+MAX2175) introduces new SDR formats only. Should it add
>>>>>>>> further SDR+MPLANE support to the framework as well?
>>>>>>>>
>>>>>>>> I would appreciate your suggestions on this regard.
>>
>> Some terminology first:
>>
>> Planar formats separate the data into different memory areas: in this case
>> one part is all I and one part is all Q. This as opposed to interleaved
>> formats (IQIQIQIQ....).
>>
>> As long as both planes fit in the same buffer all is fine. Since that is
>> the case here there is no need to introduce a new MPLANE API.
>>
>> The MPLANE API was added for video to handle cases where the two planes
>> had to be in two different non-contiguous buffers.
>
> Not only that, it can also be used for cases where storing the two planes in
> separate buffers can be beneficial, even if a single contiguous buffer could
> work.
>
>> So instead of passing one buffer pointer, you need to pass two or more
>> buffer pointers.
>>
>> In hindsight we should have called it the MBUFFER API.
>
> The name was badly chosen, yes.
>
>> Oh well...
>>
>> Anyway, since there is no problem here apparently to keep both planes
>> in one buffer there is also no need to introduce a SDR_MPLANE.
>
> The question here is whether there could be a benefit in separating I and Q
> data in two buffers compared to storing them in the same buffer.
>
The MPLANE API is very messy and introducing something like SDR_MPLANE is not
something I would promote. If we want that, then we should first make a new
v4l2_buffer struct that simplifies MPLANE handling (we discussed that before).
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-11 14:19 UTC (permalink / raw)
To: Rob Herring
Cc: Sudeep Holla, Olof Johansson, Neil Armstrong,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAL_JsqJ5PxzM_VMP55m+6snkqyWSMSsdCOiUzYWkMTb3LkD5Mw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/11/16 13:34, Rob Herring wrote:
> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>> On 10/11/16 19:03, Olof Johansson wrote:
>>> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>>> wrote:
>
> [...]
>
>>>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>>>> couple of things which we can handle with platform specific compatible
>>>> (in the following patch in the series). When another user(Rockchip ?)
>>>> make use of this legacy protocol, we can start using those platform
>>>> specific compatible for deviations only.
>>>>
>>>> Is that not acceptable ?
>>>
>>>
>>> If there's no shared legacy feature set, then it's probably less
>>> useful to have a shared less precise compatible value.
>>>
>>
>> There is and will be some shared feature set for sure. At the least the
>> standard command set will be shared.
>>
>>> What the main point I was trying to get across was that we shouldn't
>>> expand the generic binding with per-vendor compatible fields, instead
>>> we should have those as extensions on the side.
>>>
>>
>> Yes I get the point. We will have per-vendor compatibles for handle the
>> deviations but generic one to handle the shared set.
>>
>>> I'm also a little apprehensive of using "legacy", it goes in the same
>>> bucket as "misc". At some point 1.0 will be legacy too, etc.
>>>
>>
>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>
> That's still meaningless. Convince me that multiple implementations
> are identical, then we can have a common property. For example, how
> many releases did ARM make before 1.0.
>
None officially, so I tend to agree with you on this.
But so far we have seen some commonality between Rockchip and Amlogic
implementations, which in fact shares some commonality with early
release of SCPI from ARM (there are based on the same SCP code base,
which is closed source and released to partners only). ARM improved the
specification and the code base before the official release but by then
it was adopted(as usual we were late ;))
IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
and platform specific "amlogic,meson-gxbb-scpi"
--
Regards,
Sudeep
--
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 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: liviu.dudau-5wv7dgnIgG8 @ 2016-11-11 14:45 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: Arnd Bergmann,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Yuanzhichang, mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org,
minyard-HInyCGIudOg@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org,
John Garry, will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, xuwei (O),
Linuxarm, zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8F900A@lhreml507-mbx>
On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
> Hi Arnd
>
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > Sent: 10 November 2016 16:07
> > To: Gabriele Paoloni
> > Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Yuanzhichang;
> > mark.rutland-5wv7dgnIgG8@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; minyard-HInyCGIudOg@public.gmane.org; linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org; John Garry; will.deacon-5wv7dgnIgG8@public.gmane.org; linux-
> > kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; xuwei (O); Linuxarm; zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> > robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; kantyzc-9Onoh4P/yGk@public.gmane.org; linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > catalin.marinas-5wv7dgnIgG8@public.gmane.org; olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org; liviu.dudau-5wv7dgnIgG8@public.gmane.org;
> > bhelgaas@googl e.com; zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> > Hip06
> >
> > On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni wrote:
> > >
> > > Where should we get the range from? For LPC we know that it is going
> > > Work on anything that is not used by PCI I/O space, and this is
> > > why we use [0, PCIBIOS_MIN_IO]
> >
> > It should be allocated the same way we allocate PCI config space
> > segments. This is currently done with the io_range list in
> > drivers/pci/pci.c, which isn't perfect but could be extended
> > if necessary. Based on what others commented here, I'd rather
> > make the differences between ISA/LPC and PCI I/O ranges smaller
> > than larger.
Gabriele,
>
> I am not sure this would make sense...
>
> IMHO all the mechanism around io_range_list is needed to provide the
> "mapping" between I/O tokens and physical CPU addresses.
>
> Currently the available tokens range from 0 to IO_SPACE_LIMIT.
>
> As you know the I/O memory accessors operate on whatever
> __of_address_to_resource sets into the resource (start, end).
>
> With this special device in place we cannot know if a resource is
> assigned with an I/O token or a physical address, unless we forbid
> the I/O tokens to be in a specific range.
>
> So this is why we are changing the offsets of all the functions
> handling io_range_list (to make sure that a range is forbidden to
> the tokens and is available to the physical addresses).
>
> We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
> because this is the maximum physical I/O range that a non PCI device
> can operate on and because we believe this does not impose much
> restriction on the available I/O token range; that now is
> [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
> So we believe that the chosen forbidden range can accommodate
> any special ISA bus device with no much constraint on the rest
> of I/O tokens...
Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and you
actually need another variable for "reserving" an area in the I/O space
that can be used for physical addresses rather than I/O tokens.
The one good example for using PCIBIOS_MIN_IO is when your platform/architecture
does not support legacy ISA operations *at all*. In that case someone
sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O range
so that it doesn't get used. With Zhichang's patch you now start forcing
those platforms to have a valid address below PCIBIOS_MIN_IO.
For the general case you also have to bear in mind that PCIBIOS_MIN_IO could
be zero. In that case, what is your "forbidden" range? [0, 0) ? So it makes
sense to add a new #define that should only be defined by those architectures/
platforms that want to reserve on top of PCIBIOS_MIN_IO another region
where I/O tokens can't be generated for.
Best regards,
Liviu
>
> >
> > > > Your current version has
> > > >
> > > > if (arm64_extio_ops->pfout) \
> > > > arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> > > > addr, value, sizeof(type)); \
> > > >
> > > > Instead, just subtract the start of the range from the logical
> > > > port number to transform it back into a bus-local port number:
> > >
> > > These accessors do not operate on IO tokens:
> > >
> > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
> > > addr is not going to be an I/O token; in fact patch 2/3 imposes that
> > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > PCIBIOS_MIN_IO
> > > we have free physical addresses that the accessors can operate on.
> >
> > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer to
> > the logical I/O tokens, the purpose of that macro is really meant
> > for allocating PCI I/O port numbers within the address space of
> > one bus.
>
> As I mentioned above, special devices operate on CPU addresses directly,
> not I/O tokens. For them there is no way to distinguish....
>
> >
> > Note that it's equally likely that whichever next platform needs
> > non-mapped I/O access like this actually needs them for PCI I/O space,
> > and that will use it on addresses registered to a PCI host bridge.
>
> Ok so here you are talking about a platform that has got an I/O range
> under the PCI host controller, right?
> And this I/O range cannot be directly memory mapped but needs special
> redirections for the I/O tokens, right?
>
> In this scenario registering the I/O ranges with the forbidden range
> implemented by the current patch would still allow to redirect I/O
> tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
>
> So effectively the special PCI host controller
> 1) knows the physical range that needs special redirection
> 2) register such range
> 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> special accessors
> 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in 3)
>
> So to be honest I think this patch can fit well both with
> special PCI controllers that need I/O tokens redirection and with
> special non-PCI controllers that need non-PCI I/O physical
> address redirection...
>
> Thanks (and sorry for the long reply but I didn't know how
> to make the explanation shorter :) )
>
> Gab
>
> >
> > If we separate the two steps:
> >
> > a) assign a range of logical I/O port numbers to a bus
> > b) register a set of helpers for redirecting logical I/O
> > port to a helper function
> >
> > then I think the code will get cleaner and more flexible.
> > It should actually then be able to replace the powerpc
> > specific implementation.
> >
> > Arnd
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
--
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 2/3] vcodec: mediatek: Add Mediatek JPEG Decoder Driver
From: Hans Verkuil @ 2016-11-11 15:10 UTC (permalink / raw)
To: Rick Chang, Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Matthias Brugger, Rob Herring
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Minghsiu Tsai
In-Reply-To: <1478586880-3923-3-git-send-email-rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
A quick review:
On 11/08/2016 07:34 AM, Rick Chang wrote:
> Add v4l2 driver for Mediatek JPEG Decoder
>
> Signed-off-by: Rick Chang <rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> drivers/media/platform/Kconfig | 15 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/mtk-jpeg/Makefile | 2 +
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 1275 ++++++++++++++++++++++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 141 +++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c | 417 +++++++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h | 91 ++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c | 160 +++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h | 25 +
> drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 58 +
> 10 files changed, 2186 insertions(+)
> create mode 100644 drivers/media/platform/mtk-jpeg/Makefile
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 754edbf1..96c9887 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -162,6 +162,21 @@ config VIDEO_CODA
> Coda is a range of video codec IPs that supports
> H.264, MPEG-4, and other video formats.
>
> +config VIDEO_MEDIATEK_JPEG
> + tristate "Mediatek JPEG Codec driver"
> + depends on MTK_IOMMU_V1 || COMPILE_TEST
> + depends on VIDEO_DEV && VIDEO_V4L2
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + depends on HAS_DMA
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_MEM2MEM_DEV
> + ---help---
> + Mediatek jpeg codec driver provides HW capability to decode
> + JPEG format
> +
> + To compile this driver as a module, choose M here: the
> + module will be called mtk-jpeg
> +
> config VIDEO_MEDIATEK_VPU
> tristate "Mediatek Video Processor Unit"
> depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index f842933..cf701e3 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/
> obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec/
>
> obj-$(CONFIG_VIDEO_MEDIATEK_MDP) += mtk-mdp/
> +
> +obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk-jpeg/
> diff --git a/drivers/media/platform/mtk-jpeg/Makefile b/drivers/media/platform/mtk-jpeg/Makefile
> new file mode 100644
> index 0000000..b2e6069
> --- /dev/null
> +++ b/drivers/media/platform/mtk-jpeg/Makefile
> @@ -0,0 +1,2 @@
> +mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
> +obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
> diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> new file mode 100644
> index 0000000..33ddf79
> --- /dev/null
> +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> @@ -0,0 +1,1275 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: Ming Hsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> + * Rick Chang <rick.chang-NuS5LvNUpcJWk0Htik3J/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 version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/spinlock.h>
> +#include <media/v4l2-event.h>
> +#include <media/v4l2-mem2mem.h>
> +#include <media/v4l2-ioctl.h>
> +#include <media/videobuf2-core.h>
> +#include <media/videobuf2-dma-contig.h>
> +#include <soc/mediatek/smi.h>
> +#include <asm/dma-iommu.h>
> +
> +#include "mtk_jpeg_hw.h"
> +#include "mtk_jpeg_core.h"
> +#include "mtk_jpeg_parse.h"
> +
> +static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
> + {
> + .name = "JPEG JFIF",
> + .fourcc = V4L2_PIX_FMT_JPEG,
> + .colplanes = 1,
> + .flags = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
> + },
> + {
> + .name = "YUV 4:2:0 non-contiguous 3-planar, Y/Cb/Cr",
> + .fourcc = V4L2_PIX_FMT_YUV420M,
> + .h_sample = {4, 2, 2},
> + .v_sample = {4, 2, 2},
> + .colplanes = 3,
> + .h_align = 5,
> + .v_align = 4,
> + .flags = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
> + },
> + {
> + .name = "YUV 4:2:2 non-contiguous 3-planar, Y/Cb/Cr",
> + .fourcc = V4L2_PIX_FMT_YUV422M,
> + .h_sample = {4, 2, 2},
> + .v_sample = {4, 4, 4},
> + .colplanes = 3,
> + .h_align = 5,
> + .v_align = 3,
> + .flags = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
You probably don't need the name since it is filled in by the v4l2 core
(v4l2-ioctls.c).
> + },
> +};
> +
> +#define MTK_JPEG_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_formats)
> +
> +enum {
> + MTK_JPEG_BUF_FLAGS_INIT = 0,
> + MTK_JPEG_BUF_FLAGS_LAST_FRAME = 1,
> +};
> +
> +struct mtk_jpeg_src_buf {
> + struct vb2_v4l2_buffer b;
> + struct list_head list;
> + int flags;
> + struct mtk_jpeg_dec_param dec_param;
> +};
> +
> +static int debug;
> +module_param(debug, int, 0644);
> +
> +static inline struct mtk_jpeg_ctx *mtk_jpeg_fh_to_ctx(struct v4l2_fh *fh)
> +{
> + return container_of(fh, struct mtk_jpeg_ctx, fh);
> +}
> +
> +static inline struct mtk_jpeg_src_buf *mtk_jpeg_vb2_to_srcbuf(
> + struct vb2_buffer *vb)
> +{
> + return container_of(to_vb2_v4l2_buffer(vb), struct mtk_jpeg_src_buf, b);
> +}
> +
> +static int mtk_jpeg_querycap(struct file *file, void *priv,
> + struct v4l2_capability *cap)
> +{
> + struct mtk_jpeg_dev *jpeg = video_drvdata(file);
> +
> + strlcpy(cap->driver, MTK_JPEG_NAME " decoder", sizeof(cap->driver));
> + strlcpy(cap->card, MTK_JPEG_NAME " decoder", sizeof(cap->card));
> + snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
> + dev_name(jpeg->dev));
> +
> + return 0;
> +}
> +
> +static int mtk_jpeg_enum_fmt(struct mtk_jpeg_fmt *mtk_jpeg_formats, int n,
> + struct v4l2_fmtdesc *f, u32 type)
> +{
> + int i, num = 0;
> +
> + for (i = 0; i < n; ++i) {
> + if (mtk_jpeg_formats[i].flags & type) {
> + if (num == f->index)
> + break;
> + ++num;
> + }
> + }
> +
> + if (i >= n)
> + return -EINVAL;
> +
> + f->pixelformat = mtk_jpeg_formats[i].fourcc;
> +
> + return 0;
> +}
> +
> +static int mtk_jpeg_enum_fmt_vid_cap(struct file *file, void *priv,
> + struct v4l2_fmtdesc *f)
> +{
> + return mtk_jpeg_enum_fmt(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS, f,
> + MTK_JPEG_FMT_FLAG_DEC_CAPTURE);
> +}
> +
> +static int mtk_jpeg_enum_fmt_vid_out(struct file *file, void *priv,
> + struct v4l2_fmtdesc *f)
> +{
> + return mtk_jpeg_enum_fmt(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS, f,
> + MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
> +}
> +
> +static struct mtk_jpeg_q_data *mtk_jpeg_get_q_data(struct mtk_jpeg_ctx *ctx,
> + enum v4l2_buf_type type)
> +{
> + if (V4L2_TYPE_IS_OUTPUT(type))
> + return &ctx->out_q;
> + else
No need for 'else'.
> + return &ctx->cap_q;
> +}
> +
> +static struct mtk_jpeg_fmt *mtk_jpeg_find_format(struct mtk_jpeg_ctx *ctx,
> + u32 pixelformat,
> + unsigned int fmt_type)
> +{
> + unsigned int k, fmt_flag;
> +
> + fmt_flag = (fmt_type == MTK_JPEG_FMT_TYPE_OUTPUT) ?
> + MTK_JPEG_FMT_FLAG_DEC_OUTPUT :
> + MTK_JPEG_FMT_FLAG_DEC_CAPTURE;
> +
> + for (k = 0; k < MTK_JPEG_NUM_FORMATS; k++) {
> + struct mtk_jpeg_fmt *fmt = &mtk_jpeg_formats[k];
> +
> + if (fmt->fourcc == pixelformat && fmt->flags & fmt_flag)
> + return fmt;
> + }
> +
> + return NULL;
> +}
> +
> +static void mtk_jpeg_bound_align_image(u32 *w, unsigned int wmin,
> + unsigned int wmax, unsigned int walign,
> + u32 *h, unsigned int hmin,
> + unsigned int hmax, unsigned int halign)
> +{
> + int width, height, w_step, h_step;
> +
> + width = *w;
> + height = *h;
> + w_step = 1 << walign;
> + h_step = 1 << halign;
> +
> + v4l_bound_align_image(w, wmin, wmax, walign, h, hmin, hmax, halign, 0);
> + if (*w < width && (*w + w_step) <= wmax)
> + *w += w_step;
> + if (*h < height && (*h + h_step) <= hmax)
> + *h += h_step;
> +}
> +
> +static void mtk_jpeg_adjust_fmt_mplane(struct mtk_jpeg_ctx *ctx,
> + struct v4l2_format *f)
> +{
> + struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
> + struct mtk_jpeg_q_data *q_data;
> + int i;
> +
> + q_data = mtk_jpeg_get_q_data(ctx, f->type);
> +
> + pix_mp->width = q_data->w;
> + pix_mp->height = q_data->h;
> + pix_mp->pixelformat = q_data->fmt->fourcc;
> + pix_mp->num_planes = q_data->fmt->colplanes;
> +
> + for (i = 0; i < pix_mp->num_planes; i++) {
> + pix_mp->plane_fmt[i].bytesperline = q_data->bytesperline[i];
> + pix_mp->plane_fmt[i].sizeimage = q_data->sizeimage[i];
> + }
> +}
> +
> +static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
> + struct mtk_jpeg_fmt *fmt,
> + struct mtk_jpeg_ctx *ctx, int q_type)
> +{
> + struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + int i;
> +
> + memset(pix_mp->reserved, 0, sizeof(pix_mp->reserved));
> + pix_mp->field = V4L2_FIELD_NONE;
> +
> + if (ctx->state != MTK_JPEG_INIT) {
> + mtk_jpeg_adjust_fmt_mplane(ctx, f);
> + goto end;
> + }
> +
> + pix_mp->num_planes = fmt->colplanes;
> + pix_mp->pixelformat = fmt->fourcc;
> +
> + if (q_type == MTK_JPEG_FMT_TYPE_OUTPUT) {
> + struct v4l2_plane_pix_format *pfmt = &pix_mp->plane_fmt[0];
> +
> + mtk_jpeg_bound_align_image(&pix_mp->width, MTK_JPEG_MIN_WIDTH,
> + MTK_JPEG_MAX_WIDTH, 0,
> + &pix_mp->height, MTK_JPEG_MIN_HEIGHT,
> + MTK_JPEG_MAX_HEIGHT, 0);
> +
> + memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
> + pfmt->bytesperline = 0;
> + /* Source size must be aligned to 128 */
> + pfmt->sizeimage = mtk_jpeg_align(pfmt->sizeimage, 128);
> + if (pfmt->sizeimage == 0)
> + pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
> + goto end;
> + }
> +
> + /* type is MTK_JPEG_FMT_TYPE_CAPTURE */
> + mtk_jpeg_bound_align_image(&pix_mp->width, MTK_JPEG_MIN_WIDTH,
> + MTK_JPEG_MAX_WIDTH, fmt->h_align,
> + &pix_mp->height, MTK_JPEG_MIN_HEIGHT,
> + MTK_JPEG_MAX_HEIGHT, fmt->v_align);
> +
> + for (i = 0; i < fmt->colplanes; i++) {
> + struct v4l2_plane_pix_format *pfmt = &pix_mp->plane_fmt[i];
> + u32 stride = pix_mp->width * fmt->h_sample[i] / 4;
> + u32 h = pix_mp->height * fmt->v_sample[i] / 4;
> +
> + memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
> + pfmt->bytesperline = stride;
> + pfmt->sizeimage = stride * h;
> + }
> +end:
> + v4l2_dbg(2, debug, &jpeg->v4l2_dev, "wxh:%ux%u\n",
> + pix_mp->width, pix_mp->height);
> + for (i = 0; i < pix_mp->num_planes; i++) {
> + v4l2_dbg(2, debug, &jpeg->v4l2_dev,
> + "plane[%d] bpl=%u, size=%u\n",
> + i,
> + pix_mp->plane_fmt[i].bytesperline,
> + pix_mp->plane_fmt[i].sizeimage);
> + }
> + return 0;
> +}
> +
> +static int mtk_jpeg_g_fmt_vid_mplane(struct file *file, void *priv,
> + struct v4l2_format *f)
> +{
> + struct vb2_queue *vq;
> + struct mtk_jpeg_q_data *q_data = NULL;
> + struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
> + struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + int i;
> +
> + vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, f->type);
> + if (!vq)
> + return -EINVAL;
> +
> + q_data = mtk_jpeg_get_q_data(ctx, f->type);
> +
> + memset(pix_mp->reserved, 0, sizeof(pix_mp->reserved));
> + pix_mp->width = q_data->w;
> + pix_mp->height = q_data->h;
> + pix_mp->field = V4L2_FIELD_NONE;
> + pix_mp->pixelformat = q_data->fmt->fourcc;
> + pix_mp->num_planes = q_data->fmt->colplanes;
> + pix_mp->colorspace = ctx->colorspace;
> + pix_mp->ycbcr_enc = ctx->ycbcr_enc;
> + pix_mp->xfer_func = ctx->xfer_func;
> + pix_mp->quantization = ctx->quantization;
> +
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "(%d) g_fmt:%s wxh:%ux%u\n",
> + f->type, q_data->fmt->name, pix_mp->width, pix_mp->height);
> +
> + for (i = 0; i < pix_mp->num_planes; i++) {
> + struct v4l2_plane_pix_format *pfmt = &pix_mp->plane_fmt[i];
> +
> + pfmt->bytesperline = q_data->bytesperline[i];
> + pfmt->sizeimage = q_data->sizeimage[i];
> + memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
> +
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev,
> + "plane[%d] bpl=%u, size=%u\n",
> + i,
> + pfmt->bytesperline,
> + pfmt->sizeimage);
> + }
> + return 0;
> +}
> +
> +static int mtk_jpeg_try_fmt_vid_cap_mplane(struct file *file, void *priv,
> + struct v4l2_format *f)
> +{
> + struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
> + struct mtk_jpeg_fmt *fmt;
> +
> + fmt = mtk_jpeg_find_format(ctx, f->fmt.pix_mp.pixelformat,
> + MTK_JPEG_FMT_TYPE_CAPTURE);
> + if (!fmt)
> + fmt = ctx->cap_q.fmt;
> +
> + v4l2_dbg(2, debug, &ctx->jpeg->v4l2_dev, "(%d) try_fmt:%s\n",
> + f->type, fmt->name);
> +
> + return mtk_jpeg_try_fmt_mplane(f, fmt, ctx, MTK_JPEG_FMT_TYPE_CAPTURE);
> +}
> +
> +static int mtk_jpeg_try_fmt_vid_out_mplane(struct file *file, void *priv,
> + struct v4l2_format *f)
> +{
> + struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
> + struct mtk_jpeg_fmt *fmt;
> +
> + fmt = mtk_jpeg_find_format(ctx, f->fmt.pix_mp.pixelformat,
> + MTK_JPEG_FMT_TYPE_OUTPUT);
> + if (!fmt)
> + fmt = ctx->out_q.fmt;
> +
> + v4l2_dbg(2, debug, &ctx->jpeg->v4l2_dev, "(%d) try_fmt:%s\n",
> + f->type, fmt->name);
> +
> + return mtk_jpeg_try_fmt_mplane(f, fmt, ctx, MTK_JPEG_FMT_TYPE_OUTPUT);
> +}
> +
> +static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
> + struct v4l2_format *f)
> +{
> + struct vb2_queue *vq;
> + struct mtk_jpeg_q_data *q_data = NULL;
> + struct v4l2_pix_format_mplane *pix_mp = &f->fmt.pix_mp;
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + unsigned int f_type;
> + int i;
> +
> + vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, f->type);
> + if (!vq)
> + return -EINVAL;
> +
> + q_data = mtk_jpeg_get_q_data(ctx, f->type);
> +
> + if (vb2_is_busy(vq)) {
> + v4l2_err(&jpeg->v4l2_dev, "queue busy\n");
> + return -EBUSY;
> + }
> +
> + f_type = V4L2_TYPE_IS_OUTPUT(f->type) ?
> + MTK_JPEG_FMT_TYPE_OUTPUT : MTK_JPEG_FMT_TYPE_CAPTURE;
> +
> + q_data->fmt = mtk_jpeg_find_format(ctx, pix_mp->pixelformat, f_type);
> + q_data->w = pix_mp->width;
> + q_data->h = pix_mp->height;
> + ctx->colorspace = pix_mp->colorspace;
> + ctx->ycbcr_enc = pix_mp->ycbcr_enc;
> + ctx->xfer_func = pix_mp->xfer_func;
> + ctx->quantization = pix_mp->quantization;
> +
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "(%d) s_fmt:%s wxh:%ux%u\n",
> + f->type, q_data->fmt->name, q_data->w, q_data->h);
> +
> + for (i = 0; i < q_data->fmt->colplanes; i++) {
> + q_data->bytesperline[i] = pix_mp->plane_fmt[i].bytesperline;
> + q_data->sizeimage[i] = pix_mp->plane_fmt[i].sizeimage;
> +
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev,
> + "plane[%d] bpl=%u, size=%u\n",
> + i, q_data->bytesperline[i], q_data->sizeimage[i]);
> + }
> +
> + return 0;
> +}
> +
> +static int mtk_jpeg_s_fmt_vid_out_mplane(struct file *file, void *priv,
> + struct v4l2_format *f)
> +{
> + int ret;
> +
> + ret = mtk_jpeg_try_fmt_vid_out_mplane(file, priv, f);
> + if (ret)
> + return ret;
> +
> + return mtk_jpeg_s_fmt_mplane(mtk_jpeg_fh_to_ctx(priv), f);
> +}
> +
> +static int mtk_jpeg_s_fmt_vid_cap_mplane(struct file *file, void *priv,
> + struct v4l2_format *f)
> +{
> + int ret;
> +
> + ret = mtk_jpeg_try_fmt_vid_cap_mplane(file, priv, f);
> + if (ret)
> + return ret;
> +
> + return mtk_jpeg_s_fmt_mplane(mtk_jpeg_fh_to_ctx(priv), f);
> +}
> +
> +static void mtk_jpeg_queue_src_chg_event(struct mtk_jpeg_ctx *ctx)
> +{
> + static const struct v4l2_event ev_src_ch = {
> + .type = V4L2_EVENT_SOURCE_CHANGE,
> + .u.src_change.changes =
> + V4L2_EVENT_SRC_CH_RESOLUTION,
> + };
> +
> + v4l2_event_queue_fh(&ctx->fh, &ev_src_ch);
> +}
> +
> +static int mtk_jpeg_subscribe_event(struct v4l2_fh *fh,
> + const struct v4l2_event_subscription *sub)
> +{
> + switch (sub->type) {
> + case V4L2_EVENT_SOURCE_CHANGE:
> + return v4l2_src_change_event_subscribe(fh, sub);
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int mtk_jpeg_g_selection(struct file *file, void *priv,
> + struct v4l2_selection *s)
> +{
> + struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
> +
> + if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + return -EINVAL;
> +
> + switch (s->target) {
> + case V4L2_SEL_TGT_COMPOSE:
> + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> + s->r.width = ctx->out_q.w;
> + s->r.height = ctx->out_q.h;
> + s->r.left = 0;
> + s->r.top = 0;
> + break;
> + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> + case V4L2_SEL_TGT_COMPOSE_PADDED:
> + s->r.width = ctx->cap_q.w;
> + s->r.height = ctx->cap_q.h;
> + s->r.left = 0;
> + s->r.top = 0;
> + break;
> + default:
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
> +static int mtk_jpeg_s_selection(struct file *file, void *priv,
> + struct v4l2_selection *s)
> +{
> + struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
> +
> + if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> + return -EINVAL;
> +
> + switch (s->target) {
> + case V4L2_SEL_TGT_COMPOSE:
> + s->r.left = 0;
> + s->r.top = 0;
> + s->r.width = ctx->out_q.w;
> + s->r.height = ctx->out_q.h;
> + break;
> + default:
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
> +static int mtk_jpeg_qbuf(struct file *file, void *priv, struct v4l2_buffer *buf)
> +{
> + struct v4l2_fh *fh = file->private_data;
> + struct vb2_queue *vq;
> + struct vb2_buffer *vb;
> + struct mtk_jpeg_src_buf *jpeg_src_buf;
> +
> + if (buf->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> + goto end;
> +
> + vq = v4l2_m2m_get_vq(fh->m2m_ctx, buf->type);
> + vb = vq->bufs[buf->index];
> + jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(vb);
> + jpeg_src_buf->flags = (buf->m.planes[0].bytesused == 0) ?
> + MTK_JPEG_BUF_FLAGS_LAST_FRAME : MTK_JPEG_BUF_FLAGS_INIT;
> +end:
> + return v4l2_m2m_qbuf(file, fh->m2m_ctx, buf);
> +}
> +
> +static const struct v4l2_ioctl_ops mtk_jpeg_ioctl_ops = {
> + .vidioc_querycap = mtk_jpeg_querycap,
> + .vidioc_enum_fmt_vid_cap_mplane = mtk_jpeg_enum_fmt_vid_cap,
> + .vidioc_enum_fmt_vid_out_mplane = mtk_jpeg_enum_fmt_vid_out,
> + .vidioc_try_fmt_vid_cap_mplane = mtk_jpeg_try_fmt_vid_cap_mplane,
> + .vidioc_try_fmt_vid_out_mplane = mtk_jpeg_try_fmt_vid_out_mplane,
> + .vidioc_g_fmt_vid_cap_mplane = mtk_jpeg_g_fmt_vid_mplane,
> + .vidioc_g_fmt_vid_out_mplane = mtk_jpeg_g_fmt_vid_mplane,
> + .vidioc_s_fmt_vid_cap_mplane = mtk_jpeg_s_fmt_vid_cap_mplane,
> + .vidioc_s_fmt_vid_out_mplane = mtk_jpeg_s_fmt_vid_out_mplane,
> + .vidioc_qbuf = mtk_jpeg_qbuf,
> + .vidioc_subscribe_event = mtk_jpeg_subscribe_event,
> + .vidioc_g_selection = mtk_jpeg_g_selection,
> + .vidioc_s_selection = mtk_jpeg_s_selection,
> +
> + .vidioc_create_bufs = v4l2_m2m_ioctl_create_bufs,
> + .vidioc_prepare_buf = v4l2_m2m_ioctl_prepare_buf,
> + .vidioc_reqbufs = v4l2_m2m_ioctl_reqbufs,
> + .vidioc_querybuf = v4l2_m2m_ioctl_querybuf,
> + .vidioc_dqbuf = v4l2_m2m_ioctl_dqbuf,
> + .vidioc_expbuf = v4l2_m2m_ioctl_expbuf,
> + .vidioc_streamon = v4l2_m2m_ioctl_streamon,
> + .vidioc_streamoff = v4l2_m2m_ioctl_streamoff,
> +
> + .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
> +};
> +
> +static int mtk_jpeg_queue_setup(struct vb2_queue *q,
> + unsigned int *num_buffers,
> + unsigned int *num_planes,
> + unsigned int sizes[],
> + struct device *alloc_ctxs[])
> +{
> + struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> + struct mtk_jpeg_q_data *q_data = NULL;
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + int i;
> +
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "(%d) buf_req count=%u\n",
> + q->type, *num_buffers);
> +
> + q_data = mtk_jpeg_get_q_data(ctx, q->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + *num_planes = q_data->fmt->colplanes;
> + for (i = 0; i < q_data->fmt->colplanes; i++) {
> + sizes[i] = q_data->sizeimage[i];
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "sizeimage[%d]=%u\n",
> + i, sizes[i]);
> + }
> +
> + return 0;
> +}
> +
> +static int mtk_jpeg_buf_prepare(struct vb2_buffer *vb)
> +{
> + struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
> + struct mtk_jpeg_q_data *q_data = NULL;
> + int i;
> +
> + q_data = mtk_jpeg_get_q_data(ctx, vb->vb2_queue->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + for (i = 0; i < q_data->fmt->colplanes; i++)
> + vb2_set_plane_payload(vb, i, q_data->sizeimage[i]);
> +
> + return 0;
> +}
> +
> +static bool mtk_jpeg_check_resolution_change(struct mtk_jpeg_ctx *ctx,
> + struct mtk_jpeg_dec_param *param)
> +{
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct mtk_jpeg_q_data *q_data;
> +
> + q_data = &ctx->out_q;
> + if (q_data->w != param->pic_w || q_data->h != param->pic_h) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Picture size change\n");
> + return true;
> + }
> +
> + q_data = &ctx->cap_q;
> + if (q_data->fmt != mtk_jpeg_find_format(ctx, param->dst_fourcc,
> + MTK_JPEG_FMT_TYPE_CAPTURE)) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "format change\n");
> + return true;
> + }
> + return false;
> +}
> +
> +static void mtk_jpeg_set_queue_data(struct mtk_jpeg_ctx *ctx,
> + struct mtk_jpeg_dec_param *param)
> +{
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct mtk_jpeg_q_data *q_data;
> + int i;
> +
> + q_data = &ctx->out_q;
> + q_data->w = param->pic_w;
> + q_data->h = param->pic_h;
> +
> + q_data = &ctx->cap_q;
> + q_data->w = param->dec_w;
> + q_data->h = param->dec_h;
> + q_data->fmt = mtk_jpeg_find_format(ctx,
> + param->dst_fourcc,
> + MTK_JPEG_FMT_TYPE_CAPTURE);
> +
> + for (i = 0; i < q_data->fmt->colplanes; i++) {
> + q_data->bytesperline[i] = param->mem_stride[i];
> + q_data->sizeimage[i] = param->comp_size[i];
> + }
> +
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev,
> + "set_parse cap:%s pic(%u, %u), buf(%u, %u)\n",
> + q_data->fmt->name, param->pic_w, param->pic_h,
> + param->dec_w, param->dec_h);
> +}
> +
> +static void mtk_jpeg_buf_queue(struct vb2_buffer *vb)
> +{
> + struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
> + struct mtk_jpeg_dec_param *param;
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct mtk_jpeg_src_buf *jpeg_src_buf;
> + bool header_valid;
> +
> + v4l2_dbg(2, debug, &jpeg->v4l2_dev, "(%d) buf_q id=%d, vb=%p",
> + vb->vb2_queue->type, vb->index, vb);
> +
> + if (vb->vb2_queue->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> + goto end;
> +
> + jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(vb);
> + param = &jpeg_src_buf->dec_param;
> + memset(param, 0, sizeof(*param));
> +
> + if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
> + v4l2_dbg(1, debug, &jpeg->v4l2_dev, "Got eos");
> + goto end;
> + }
> + header_valid = mtk_jpeg_parse(param, (u8 *)vb2_plane_vaddr(vb, 0),
> + vb2_get_plane_payload(vb, 0));
> + if (!header_valid) {
> + v4l2_err(&jpeg->v4l2_dev, "Header invalid.\n");
> + vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
> + return;
> + }
> +
> + if (ctx->state == MTK_JPEG_INIT) {
> + mtk_jpeg_queue_src_chg_event(ctx);
> + mtk_jpeg_set_queue_data(ctx, param);
> + ctx->state = MTK_JPEG_RUNNING;
> + }
> +end:
> + v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, to_vb2_v4l2_buffer(vb));
> +}
> +
> +static void *mtk_jpeg_buf_remove(struct mtk_jpeg_ctx *ctx,
> + enum v4l2_buf_type type)
> +{
> + if (V4L2_TYPE_IS_OUTPUT(type))
> + return v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + else
> + return v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> +}
> +
> +static int mtk_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
> +{
> + struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> + int ret = 0;
> +
> + ret = pm_runtime_get_sync(ctx->jpeg->dev);
> +
If start_streaming returns an error, then you must call
v4l2_m2m_buf_done(to_vb2_v4l2_buffer(vb), VB2_BUF_STATE_QUEUED) for all
buffers. Similar to what happens in stop_streaming, but with a different VB2_BUF_STATE.
> + return ret > 0 ? 0 : ret;
> +}
> +
> +static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
> +{
> + struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> + struct vb2_buffer *vb;
> +
> + /*
> + * STREAMOFF is an acknowledgment for source change event.
> + * Before STREAMOFF, we still have to return the old resolution and
> + * subsampling. Update capture queue when the stream is off.
> + */
> + if (ctx->state == MTK_JPEG_SOURCE_CHANGE &&
> + !V4L2_TYPE_IS_OUTPUT(q->type)) {
> + struct mtk_jpeg_src_buf *src_buf;
> +
> + vb = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> + src_buf = mtk_jpeg_vb2_to_srcbuf(vb);
> + mtk_jpeg_set_queue_data(ctx, &src_buf->dec_param);
> + ctx->state = MTK_JPEG_RUNNING;
> + } else if (V4L2_TYPE_IS_OUTPUT(q->type)) {
> + ctx->state = MTK_JPEG_INIT;
> + }
> +
> + vb = mtk_jpeg_buf_remove(ctx, q->type);
> + while (vb) {
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(vb), VB2_BUF_STATE_ERROR);
> + vb = mtk_jpeg_buf_remove(ctx, q->type);
> + }
> +
> + pm_runtime_put_sync(ctx->jpeg->dev);
> +}
> +
> +static struct vb2_ops mtk_jpeg_qops = {
> + .queue_setup = mtk_jpeg_queue_setup,
> + .buf_prepare = mtk_jpeg_buf_prepare,
> + .buf_queue = mtk_jpeg_buf_queue,
> + .wait_prepare = vb2_ops_wait_prepare,
> + .wait_finish = vb2_ops_wait_finish,
> + .start_streaming = mtk_jpeg_start_streaming,
> + .stop_streaming = mtk_jpeg_stop_streaming,
> +};
> +
> +static void mtk_jpeg_set_dec_src(struct mtk_jpeg_ctx *ctx,
> + struct vb2_buffer *src_buf,
> + struct mtk_jpeg_bs *bs)
> +{
> + bs->str_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
> + bs->end_addr = bs->str_addr +
> + mtk_jpeg_align(vb2_get_plane_payload(src_buf, 0), 16);
> + bs->size = mtk_jpeg_align(vb2_plane_size(src_buf, 0), 128);
> +}
> +
> +static int mtk_jpeg_set_dec_dst(struct mtk_jpeg_ctx *ctx,
> + struct mtk_jpeg_dec_param *param,
> + struct vb2_buffer *dst_buf,
> + struct mtk_jpeg_fb *fb)
> +{
> + int i;
> +
> + if (param->comp_num != dst_buf->num_planes) {
> + dev_err(ctx->jpeg->dev, "plane number mismatch (%u != %u)\n",
> + param->comp_num, dst_buf->num_planes);
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < dst_buf->num_planes; i++) {
> + if (vb2_plane_size(dst_buf, i) < param->comp_size[i]) {
> + dev_err(ctx->jpeg->dev,
> + "buffer size is underflow (%lu < %u)\n",
> + vb2_plane_size(dst_buf, 0),
> + param->comp_size[i]);
> + return -EINVAL;
> + }
> + fb->plane_addr[i] = vb2_dma_contig_plane_dma_addr(dst_buf, i);
> + }
> +
> + return 0;
> +}
> +
> +static void mtk_jpeg_device_run(void *priv)
> +{
> + struct mtk_jpeg_ctx *ctx = priv;
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct vb2_buffer *src_buf, *dst_buf;
> + enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> + unsigned long flags;
> + struct mtk_jpeg_src_buf *jpeg_src_buf;
> + struct mtk_jpeg_bs bs;
> + struct mtk_jpeg_fb fb;
> + int i;
> +
> + src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> + jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
> +
> + if (jpeg_src_buf->flags & MTK_JPEG_BUF_FLAGS_LAST_FRAME) {
> + for (i = 0; i < dst_buf->num_planes; i++)
> + vb2_set_plane_payload(dst_buf, i, 0);
> + buf_state = VB2_BUF_STATE_DONE;
> + goto dec_end;
> + }
> +
> + if (mtk_jpeg_check_resolution_change(ctx, &jpeg_src_buf->dec_param)) {
> + mtk_jpeg_queue_src_chg_event(ctx);
> + ctx->state = MTK_JPEG_SOURCE_CHANGE;
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> + return;
> + }
> +
> + mtk_jpeg_set_dec_src(ctx, src_buf, &bs);
> + if (mtk_jpeg_set_dec_dst(ctx, &jpeg_src_buf->dec_param, dst_buf, &fb))
> + goto dec_end;
> +
> + spin_lock_irqsave(&jpeg->hw_lock, flags);
> + mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> + mtk_jpeg_dec_set_config(jpeg->dec_reg_base,
> + &jpeg_src_buf->dec_param, &bs, &fb);
> +
> + mtk_jpeg_dec_start(jpeg->dec_reg_base);
> + spin_unlock_irqrestore(&jpeg->hw_lock, flags);
> + return;
> +
> +dec_end:
> + v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), buf_state);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), buf_state);
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> +}
> +
> +static int mtk_jpeg_job_ready(void *priv)
> +{
> + struct mtk_jpeg_ctx *ctx = priv;
> +
> + return (ctx->state == MTK_JPEG_RUNNING) ? 1 : 0;
> +}
> +
> +static void mtk_jpeg_job_abort(void *priv)
> +{
> + struct mtk_jpeg_ctx *ctx = priv;
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> + struct vb2_buffer *src_buf, *dst_buf;
> +
> + src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), VB2_BUF_STATE_ERROR);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), VB2_BUF_STATE_ERROR);
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> +}
> +
> +static struct v4l2_m2m_ops mtk_jpeg_m2m_ops = {
> + .device_run = mtk_jpeg_device_run,
> + .job_ready = mtk_jpeg_job_ready,
> + .job_abort = mtk_jpeg_job_abort,
> +};
> +
> +static int mtk_jpeg_queue_init(void *priv, struct vb2_queue *src_vq,
> + struct vb2_queue *dst_vq)
> +{
> + struct mtk_jpeg_ctx *ctx = priv;
> + int ret;
> +
> + src_vq->type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> + src_vq->io_modes = VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
I would drop USERPTR, it really makes little sense for dma_contig.
> + src_vq->drv_priv = ctx;
> + src_vq->buf_struct_size = sizeof(struct mtk_jpeg_src_buf);
> + src_vq->ops = &mtk_jpeg_qops;
> + src_vq->mem_ops = &vb2_dma_contig_memops;
> + src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> + src_vq->lock = &ctx->jpeg->lock;
> + src_vq->dev = ctx->jpeg->dev;
> + ret = vb2_queue_init(src_vq);
> + if (ret)
> + return ret;
> +
> + dst_vq->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> + dst_vq->io_modes = VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
Ditto.
> + dst_vq->drv_priv = ctx;
> + dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
> + dst_vq->ops = &mtk_jpeg_qops;
> + dst_vq->mem_ops = &vb2_dma_contig_memops;
> + dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> + dst_vq->lock = &ctx->jpeg->lock;
> + dst_vq->dev = ctx->jpeg->dev;
> + ret = vb2_queue_init(dst_vq);
> +
> + return ret;
> +}
> +
> +static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
> +{
> + int ret;
> +
> + ret = mtk_smi_larb_get(jpeg->larb);
> + if (ret)
> + dev_err(jpeg->dev, "mtk_smi_larb_get larbvdec fail %d\n", ret);
> + clk_prepare_enable(jpeg->clk_jdec_smi);
> + clk_prepare_enable(jpeg->clk_jdec);
> +}
> +
> +static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg)
> +{
> + clk_disable_unprepare(jpeg->clk_jdec);
> + clk_disable_unprepare(jpeg->clk_jdec_smi);
> + mtk_smi_larb_put(jpeg->larb);
> +}
> +
> +static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
> +{
> + struct mtk_jpeg_dev *jpeg = priv;
> + struct mtk_jpeg_ctx *ctx;
> + struct vb2_buffer *src_buf, *dst_buf;
> + struct mtk_jpeg_src_buf *jpeg_src_buf;
> + enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> + u32 dec_irq_ret;
> + u32 dec_ret;
> + int i;
> +
> + ctx = v4l2_m2m_get_curr_priv(jpeg->m2m_dev);
> + if (!ctx) {
> + v4l2_err(&jpeg->v4l2_dev, "Context is NULL\n");
> + return IRQ_HANDLED;
> + }
> +
> + src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
> +
> + dec_ret = mtk_jpeg_dec_get_int_status(jpeg->dec_reg_base);
> + dec_irq_ret = mtk_jpeg_dec_enum_result(dec_ret);
> +
> + if (dec_irq_ret >= MTK_JPEG_DEC_RESULT_UNDERFLOW)
> + mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> +
> + if (dec_irq_ret != MTK_JPEG_DEC_RESULT_EOF_DONE) {
> + dev_err(jpeg->dev, "decode failed\n");
> + goto dec_end;
> + }
> +
> + for (i = 0; i < dst_buf->num_planes; i++)
> + vb2_set_plane_payload(dst_buf, i,
> + jpeg_src_buf->dec_param.comp_size[i]);
> +
> + buf_state = VB2_BUF_STATE_DONE;
> +
> +dec_end:
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), buf_state);
> + v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), buf_state);
> + v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
> + return IRQ_HANDLED;
> +}
> +
> +static void mtk_jpeg_set_default_params(struct mtk_jpeg_ctx *ctx)
> +{
> + struct mtk_jpeg_q_data *q = &ctx->out_q;
> + int i;
> +
> + ctx->colorspace = V4L2_COLORSPACE_JPEG,
> + ctx->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
> + ctx->quantization = V4L2_QUANTIZATION_DEFAULT;
> + ctx->xfer_func = V4L2_XFER_FUNC_DEFAULT;
> +
> + q->fmt = mtk_jpeg_find_format(ctx, V4L2_PIX_FMT_JPEG,
> + MTK_JPEG_FMT_TYPE_OUTPUT);
> + q->w = MTK_JPEG_MIN_WIDTH;
> + q->h = MTK_JPEG_MIN_HEIGHT;
> + q->bytesperline[0] = 0;
> + q->sizeimage[0] = MTK_JPEG_DEFAULT_SIZEIMAGE;
> +
> + q = &ctx->cap_q;
> + q->fmt = mtk_jpeg_find_format(ctx, V4L2_PIX_FMT_YUV420M,
> + MTK_JPEG_FMT_TYPE_CAPTURE);
> + q->w = MTK_JPEG_MIN_WIDTH;
> + q->h = MTK_JPEG_MIN_HEIGHT;
> +
> + for (i = 0; i < q->fmt->colplanes; i++) {
> + u32 stride = q->w * q->fmt->h_sample[i] / 4;
> + u32 h = q->h * q->fmt->v_sample[i] / 4;
> +
> + q->bytesperline[i] = stride;
> + q->sizeimage[i] = stride * h;
> + }
> +}
> +
> +static int mtk_jpeg_open(struct file *file)
> +{
> + struct mtk_jpeg_dev *jpeg = video_drvdata(file);
> + struct video_device *vfd = video_devdata(file);
> + struct mtk_jpeg_ctx *ctx;
> + int ret = 0;
> +
> + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + if (mutex_lock_interruptible(&jpeg->lock)) {
> + ret = -ERESTARTSYS;
> + goto free;
> + }
> +
> + v4l2_fh_init(&ctx->fh, vfd);
> + file->private_data = &ctx->fh;
> + v4l2_fh_add(&ctx->fh);
> +
> + ctx->jpeg = jpeg;
> + ctx->fh.m2m_ctx = v4l2_m2m_ctx_init(jpeg->m2m_dev, ctx,
> + mtk_jpeg_queue_init);
> + if (IS_ERR(ctx->fh.m2m_ctx)) {
> + ret = PTR_ERR(ctx->fh.m2m_ctx);
> + goto error;
> + }
> +
> + mtk_jpeg_set_default_params(ctx);
> + mutex_unlock(&jpeg->lock);
> + return 0;
> +
> +error:
> + v4l2_fh_del(&ctx->fh);
> + v4l2_fh_exit(&ctx->fh);
> + mutex_unlock(&jpeg->lock);
> +free:
> + kfree(ctx);
> + return ret;
> +}
> +
> +static int mtk_jpeg_release(struct file *file)
> +{
> + struct mtk_jpeg_dev *jpeg = video_drvdata(file);
> + struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(file->private_data);
> +
> + mutex_lock(&jpeg->lock);
> + v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
> + v4l2_fh_del(&ctx->fh);
> + v4l2_fh_exit(&ctx->fh);
> + kfree(ctx);
> + mutex_unlock(&jpeg->lock);
> + return 0;
> +}
> +
> +static const struct v4l2_file_operations mtk_jpeg_fops = {
> + .owner = THIS_MODULE,
> + .open = mtk_jpeg_open,
> + .release = mtk_jpeg_release,
> + .poll = v4l2_m2m_fop_poll,
> + .unlocked_ioctl = video_ioctl2,
> + .mmap = v4l2_m2m_fop_mmap,
> +};
> +
> +static int mtk_jpeg_clk_init(struct mtk_jpeg_dev *jpeg)
> +{
> + struct device_node *node;
> + struct platform_device *pdev;
> +
> + node = of_parse_phandle(jpeg->dev->of_node, "mediatek,larb", 0);
> + if (!node)
> + return -EINVAL;
> + pdev = of_find_device_by_node(node);
> + if (WARN_ON(!pdev)) {
> + of_node_put(node);
> + return -EINVAL;
> + }
> + of_node_put(node);
> +
> + jpeg->larb = &pdev->dev;
> +
> + jpeg->clk_jdec = devm_clk_get(jpeg->dev, "jpgdec");
> + if (IS_ERR(jpeg->clk_jdec))
> + return -EINVAL;
> +
> + jpeg->clk_jdec_smi = devm_clk_get(jpeg->dev, "jpgdec-smi");
> + if (IS_ERR(jpeg->clk_jdec_smi))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int mtk_jpeg_probe(struct platform_device *pdev)
> +{
> + struct mtk_jpeg_dev *jpeg;
> + struct resource *res;
> + int dec_irq;
> + int ret;
> +
> + jpeg = devm_kzalloc(&pdev->dev, sizeof(*jpeg), GFP_KERNEL);
> + if (!jpeg)
> + return -ENOMEM;
> +
> + mutex_init(&jpeg->lock);
> + spin_lock_init(&jpeg->hw_lock);
> + jpeg->dev = &pdev->dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + jpeg->dec_reg_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(jpeg->dec_reg_base)) {
> + ret = PTR_ERR(jpeg->dec_reg_base);
> + return ret;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + dec_irq = platform_get_irq(pdev, 0);
> + if (!res || dec_irq < 0) {
> + dev_err(&pdev->dev, "Failed to get dec_irq %d.\n", dec_irq);
> + ret = -EINVAL;
> + return ret;
> + }
> +
> + ret = devm_request_irq(&pdev->dev, dec_irq, mtk_jpeg_dec_irq, 0,
> + pdev->name, jpeg);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to request dec_irq %d (%d)\n",
> + dec_irq, ret);
> + ret = -EINVAL;
> + goto err_req_irq;
> + }
> +
> + ret = mtk_jpeg_clk_init(jpeg);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to init clk, err %d\n", ret);
> + goto err_clk_init;
> + }
> +
> + ret = v4l2_device_register(&pdev->dev, &jpeg->v4l2_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to register v4l2 device\n");
> + ret = -EINVAL;
> + goto err_dev_register;
> + }
> +
> + jpeg->m2m_dev = v4l2_m2m_init(&mtk_jpeg_m2m_ops);
> + if (IS_ERR(jpeg->m2m_dev)) {
> + v4l2_err(&jpeg->v4l2_dev, "Failed to init mem2mem device\n");
> + ret = PTR_ERR(jpeg->m2m_dev);
> + goto err_m2m_init;
> + }
> +
> + jpeg->dec_vdev = video_device_alloc();
> + if (!jpeg->dec_vdev) {
> + ret = -ENOMEM;
> + goto err_dec_vdev_alloc;
> + }
> + snprintf(jpeg->dec_vdev->name, sizeof(jpeg->dec_vdev->name),
> + "%s-dec", MTK_JPEG_NAME);
> + jpeg->dec_vdev->fops = &mtk_jpeg_fops;
> + jpeg->dec_vdev->ioctl_ops = &mtk_jpeg_ioctl_ops;
> + jpeg->dec_vdev->minor = -1;
> + jpeg->dec_vdev->release = video_device_release;
> + jpeg->dec_vdev->lock = &jpeg->lock;
> + jpeg->dec_vdev->v4l2_dev = &jpeg->v4l2_dev;
> + jpeg->dec_vdev->vfl_dir = VFL_DIR_M2M;
> + jpeg->dec_vdev->device_caps = V4L2_CAP_STREAMING |
> + V4L2_CAP_VIDEO_M2M_MPLANE;
> +
> + ret = video_register_device(jpeg->dec_vdev, VFL_TYPE_GRABBER, 3);
> + if (ret) {
> + v4l2_err(&jpeg->v4l2_dev, "Failed to register video device\n");
> + goto err_dec_vdev_register;
> + }
> +
> + video_set_drvdata(jpeg->dec_vdev, jpeg);
> + v4l2_info(&jpeg->v4l2_dev,
> + "decoder device registered as /dev/video%d (%d,%d)\n",
> + jpeg->dec_vdev->num, VIDEO_MAJOR, jpeg->dec_vdev->minor);
> +
> + platform_set_drvdata(pdev, jpeg);
> +
> + pm_runtime_enable(&pdev->dev);
> +
> + return 0;
> +
> +err_dec_vdev_register:
> + video_device_release(jpeg->dec_vdev);
> +
> +err_dec_vdev_alloc:
> + v4l2_m2m_release(jpeg->m2m_dev);
> +
> +err_m2m_init:
> + v4l2_device_unregister(&jpeg->v4l2_dev);
> +
> +err_dev_register:
> +
> +err_clk_init:
> +
> +err_req_irq:
> +
> + return ret;
> +}
> +
> +static int mtk_jpeg_remove(struct platform_device *pdev)
> +{
> + struct mtk_jpeg_dev *jpeg = platform_get_drvdata(pdev);
> +
> + pm_runtime_disable(&pdev->dev);
> + video_unregister_device(jpeg->dec_vdev);
> + video_device_release(jpeg->dec_vdev);
> + v4l2_m2m_release(jpeg->m2m_dev);
> + v4l2_device_unregister(&jpeg->v4l2_dev);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +static int mtk_jpeg_pm_suspend(struct device *dev)
> +{
> + struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
> +
> + mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> + mtk_jpeg_clk_off(jpeg);
> +
> + return 0;
> +}
> +
> +static int mtk_jpeg_pm_resume(struct device *dev)
> +{
> + struct mtk_jpeg_dev *jpeg = dev_get_drvdata(dev);
> +
> + mtk_jpeg_clk_on(jpeg);
> + mtk_jpeg_dec_reset(jpeg->dec_reg_base);
> +
> + return 0;
> +}
> +#endif /* CONFIG_PM */
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int mtk_jpeg_suspend(struct device *dev)
> +{
> + int ret;
> +
> + if (pm_runtime_suspended(dev))
> + return 0;
> +
> + ret = mtk_jpeg_pm_suspend(dev);
> + return ret;
> +}
> +
> +static int mtk_jpeg_resume(struct device *dev)
> +{
> + int ret;
> +
> + if (pm_runtime_suspended(dev))
> + return 0;
> +
> + ret = mtk_jpeg_pm_resume(dev);
> +
> + return ret;
> +}
> +#endif /* CONFIG_PM_SLEEP */
> +
> +static const struct dev_pm_ops mtk_jpeg_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(mtk_jpeg_suspend, mtk_jpeg_resume)
> + SET_RUNTIME_PM_OPS(mtk_jpeg_pm_suspend, mtk_jpeg_pm_resume, NULL)
> +};
> +
> +static const struct of_device_id mtk_jpeg_match[] = {
> + {
> + .compatible = "mediatek,mt8173-jpgdec",
> + .data = NULL,
> + },
> + {
> + .compatible = "mediatek,mt2701-jpgdec",
> + .data = NULL,
> + },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, mtk_jpeg_match);
> +
> +static struct platform_driver mtk_jpeg_driver = {
> + .probe = mtk_jpeg_probe,
> + .remove = mtk_jpeg_remove,
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = MTK_JPEG_NAME,
> + .of_match_table = mtk_jpeg_match,
> + .pm = &mtk_jpeg_pm_ops,
> + },
> +};
> +
> +module_platform_driver(mtk_jpeg_driver);
> +
> +MODULE_DESCRIPTION("MediaTek JPEG codec driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> new file mode 100644
> index 0000000..d862e3b
> --- /dev/null
> +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> @@ -0,0 +1,141 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: Ming Hsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> + * Rick Chang <rick.chang-NuS5LvNUpcJWk0Htik3J/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 version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef _MTK_JPEG_CORE_H
> +#define _MTK_JPEG_CORE_H
> +
> +#include <linux/interrupt.h>
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-fh.h>
> +
> +#define MTK_JPEG_NAME "mtk-jpeg"
> +
> +#define MTK_JPEG_FMT_FLAG_DEC_OUTPUT BIT(0)
> +#define MTK_JPEG_FMT_FLAG_DEC_CAPTURE BIT(1)
> +
> +#define MTK_JPEG_FMT_TYPE_OUTPUT 1
> +#define MTK_JPEG_FMT_TYPE_CAPTURE 2
> +
> +#define MTK_JPEG_MIN_WIDTH 32
> +#define MTK_JPEG_MIN_HEIGHT 32
> +#define MTK_JPEG_MAX_WIDTH 8192
> +#define MTK_JPEG_MAX_HEIGHT 8192
> +
> +#define MTK_JPEG_DEFAULT_SIZEIMAGE (1 * 1024 * 1024)
> +
> +enum mtk_jpeg_ctx_state {
> + MTK_JPEG_INIT = 0,
> + MTK_JPEG_RUNNING,
> + MTK_JPEG_SOURCE_CHANGE,
> +};
> +
> +/**
> + * struct mt_jpeg - JPEG IP abstraction
> + * @lock: the mutex protecting this structure
> + * @hw_lock: spinlock protecting the hw device resource
> + * @workqueue: decode work queue
> + * @dev: JPEG device
> + * @v4l2_dev: v4l2 device for mem2mem mode
> + * @m2m_dev: v4l2 mem2mem device data
> + * @alloc_ctx: videobuf2 memory allocator's context
> + * @dec_vdev: video device node for decoder mem2mem mode
> + * @dec_reg_base: JPEG registers mapping
> + * @clk_jdec: JPEG hw working clock
> + * @clk_jdec_smi: JPEG SMI bus clock
> + * @larb: SMI device
> + */
> +struct mtk_jpeg_dev {
> + struct mutex lock;
> + spinlock_t hw_lock;
> + struct workqueue_struct *workqueue;
> + struct device *dev;
> + struct v4l2_device v4l2_dev;
> + struct v4l2_m2m_dev *m2m_dev;
> + void *alloc_ctx;
> + struct video_device *dec_vdev;
> + void __iomem *dec_reg_base;
> + struct clk *clk_jdec;
> + struct clk *clk_jdec_smi;
> + struct device *larb;
> +};
> +
> +/**
> + * struct jpeg_fmt - driver's internal color format data
> + * @name: format descritpion
> + * @fourcc: the fourcc code, 0 if not applicable
> + * @h_sample: horizontal sample count of plane in 4 * 4 pixel image
> + * @v_sample: vertical sample count of plane in 4 * 4 pixel image
> + * @colplanes: number of color planes (1 for packed formats)
> + * @h_align: horizontal alignment order (align to 2^h_align)
> + * @v_align: vertical alignment order (align to 2^v_align)
> + * @flags: flags describing format applicability
> + */
> +struct mtk_jpeg_fmt {
> + char *name;
> + u32 fourcc;
> + int h_sample[VIDEO_MAX_PLANES];
> + int v_sample[VIDEO_MAX_PLANES];
> + int colplanes;
> + int h_align;
> + int v_align;
> + u32 flags;
> +};
> +
> +/**
> + * mtk_jpeg_q_data - parameters of one queue
> + * @fmt: driver-specific format of this queue
> + * @w: image width
> + * @h: image height
> + * @bytesperline: distance in bytes between the leftmost pixels in two adjacent
> + * lines
> + * @sizeimage: image buffer size in bytes
> + */
> +struct mtk_jpeg_q_data {
> + struct mtk_jpeg_fmt *fmt;
> + u32 w;
> + u32 h;
> + u32 bytesperline[VIDEO_MAX_PLANES];
> + u32 sizeimage[VIDEO_MAX_PLANES];
> +};
> +
> +/**
> + * mtk_jpeg_ctx - the device context data
> + * @jpeg: JPEG IP device for this context
> + * @out_q: source (output) queue information
> + * @cap_q: destination (capture) queue queue information
> + * @fh: V4L2 file handle
> + * @dec_param parameters for HW decoding
> + * @state: state of the context
> + * @header_valid: set if header has been parsed and valid
> + * @colorspace: enum v4l2_colorspace; supplemental to pixelformat
> + * @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
> + * @quantization: enum v4l2_quantization, colorspace quantization
> + * @xfer_func: enum v4l2_xfer_func, colorspace transfer function
> + */
> +struct mtk_jpeg_ctx {
> + struct mtk_jpeg_dev *jpeg;
> + struct mtk_jpeg_q_data out_q;
> + struct mtk_jpeg_q_data cap_q;
> + struct v4l2_fh fh;
> + enum mtk_jpeg_ctx_state state;
> +
> + enum v4l2_colorspace colorspace;
> + enum v4l2_ycbcr_encoding ycbcr_enc;
> + enum v4l2_quantization quantization;
> + enum v4l2_xfer_func xfer_func;
> +};
> +
> +#endif /* _MTK_JPEG_CORE_H */
> diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c b/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
> new file mode 100644
> index 0000000..a6315f3
> --- /dev/null
> +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
> @@ -0,0 +1,417 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: Ming Hsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> + * Rick Chang <rick.chang-NuS5LvNUpcJWk0Htik3J/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 version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <media/videobuf2-core.h>
> +
> +#include "mtk_jpeg_hw.h"
> +
> +#define MTK_JPEG_DUNUM_MASK(val) (((val) - 1) & 0x3)
> +
> +enum mtk_jpeg_color {
> + MTK_JPEG_COLOR_420 = 0x00221111,
> + MTK_JPEG_COLOR_422 = 0x00211111,
> + MTK_JPEG_COLOR_444 = 0x00111111,
> + MTK_JPEG_COLOR_422V = 0x00121111,
> + MTK_JPEG_COLOR_422X2 = 0x00412121,
> + MTK_JPEG_COLOR_422VX2 = 0x00222121,
> + MTK_JPEG_COLOR_400 = 0x00110000
> +};
> +
> +static inline int mtk_jpeg_verify_align(u32 val, int align, u32 reg)
> +{
> + if (val & (align - 1)) {
> + pr_err("mtk-jpeg: write reg %x without %d align\n", reg, align);
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static int mtk_jpeg_decide_format(struct mtk_jpeg_dec_param *param)
> +{
> + param->src_color = (param->sampling_w[0] << 20) |
> + (param->sampling_h[0] << 16) |
> + (param->sampling_w[1] << 12) |
> + (param->sampling_h[1] << 8) |
> + (param->sampling_w[2] << 4) |
> + (param->sampling_h[2]);
> +
> + param->uv_brz_w = 0;
> + switch (param->src_color) {
> + case MTK_JPEG_COLOR_444:
> + param->uv_brz_w = 1;
> + param->dst_fourcc = V4L2_PIX_FMT_YUV422M;
> + break;
> + case MTK_JPEG_COLOR_422X2:
> + case MTK_JPEG_COLOR_422:
> + param->dst_fourcc = V4L2_PIX_FMT_YUV422M;
> + break;
> + case MTK_JPEG_COLOR_422V:
> + case MTK_JPEG_COLOR_422VX2:
> + param->uv_brz_w = 1;
> + param->dst_fourcc = V4L2_PIX_FMT_YUV420M;
> + break;
> + case MTK_JPEG_COLOR_420:
> + param->dst_fourcc = V4L2_PIX_FMT_YUV420M;
> + break;
> + case MTK_JPEG_COLOR_400:
> + param->dst_fourcc = V4L2_PIX_FMT_GREY;
> + break;
> + default:
> + param->dst_fourcc = 0;
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static void mtk_jpeg_calc_mcu(struct mtk_jpeg_dec_param *param)
> +{
> + u32 factor_w, factor_h;
> + u32 i, comp, blk;
> +
> + factor_w = 2 + param->sampling_w[0];
> + factor_h = 2 + param->sampling_h[0];
> + param->mcu_w = (param->pic_w + (1 << factor_w) - 1) >> factor_w;
> + param->mcu_h = (param->pic_h + (1 << factor_h) - 1) >> factor_h;
> + param->total_mcu = param->mcu_w * param->mcu_h;
> + param->unit_num = ((param->pic_w + 7) >> 3) * ((param->pic_h + 7) >> 3);
> + param->blk_num = 0;
> + for (i = 0; i < MTK_JPEG_COMP_MAX; i++) {
> + param->blk_comp[i] = 0;
> + if (i >= param->comp_num)
> + continue;
> + param->blk_comp[i] = param->sampling_w[i] *
> + param->sampling_h[i];
> + param->blk_num += param->blk_comp[i];
> + }
> +
> + param->membership = 0;
> + for (i = 0, blk = 0, comp = 0; i < MTK_JPEG_BLOCK_MAX; i++) {
> + if (i < param->blk_num && comp < param->comp_num) {
> + u32 tmp;
> +
> + tmp = (0x04 + (comp & 0x3));
> + param->membership |= tmp << (i * 3);
> + if (++blk == param->blk_comp[comp]) {
> + comp++;
> + blk = 0;
> + }
> + } else {
> + param->membership |= 7 << (i * 3);
> + }
> + }
> +}
> +
> +static void mtk_jpeg_calc_dma_group(struct mtk_jpeg_dec_param *param)
> +{
> + u32 factor_mcu = 3;
> +
> + if (param->src_color == MTK_JPEG_COLOR_444 &&
> + param->dst_fourcc == V4L2_PIX_FMT_YUV422M)
> + factor_mcu = 4;
> + else if (param->src_color == MTK_JPEG_COLOR_422V &&
> + param->dst_fourcc == V4L2_PIX_FMT_YUV420M)
> + factor_mcu = 4;
> + else if (param->src_color == MTK_JPEG_COLOR_422X2 &&
> + param->dst_fourcc == V4L2_PIX_FMT_YUV422M)
> + factor_mcu = 2;
> + else if (param->src_color == MTK_JPEG_COLOR_400 ||
> + (param->src_color & 0x0FFFF) == 0)
> + factor_mcu = 4;
> +
> + param->dma_mcu = 1 << factor_mcu;
> + param->dma_group = param->mcu_w / param->dma_mcu;
> + param->dma_last_mcu = param->mcu_w % param->dma_mcu;
> + if (param->dma_last_mcu)
> + param->dma_group++;
> + else
> + param->dma_last_mcu = param->dma_mcu;
> +}
> +
> +static int mtk_jpeg_calc_dst_size(struct mtk_jpeg_dec_param *param)
> +{
> + u32 i, padding_w;
> + u32 ds_row_h[3];
> + u32 brz_w[3];
> +
> + brz_w[0] = 0;
> + brz_w[1] = param->uv_brz_w;
> + brz_w[2] = brz_w[1];
> +
> + for (i = 0; i < param->comp_num; i++) {
> + if (brz_w[i] > 3)
> + return -1;
> +
> + padding_w = param->mcu_w * MTK_JPEG_DCTSIZE *
> + param->sampling_w[i];
> + /* output format is 420/422 */
> + param->comp_w[i] = padding_w >> brz_w[i];
> + param->comp_w[i] = mtk_jpeg_align(param->comp_w[i],
> + MTK_JPEG_DCTSIZE);
> + param->img_stride[i] = i ? mtk_jpeg_align(param->comp_w[i], 16)
> + : mtk_jpeg_align(param->comp_w[i], 32);
> + ds_row_h[i] = (MTK_JPEG_DCTSIZE * param->sampling_h[i]);
> + }
> + param->dec_w = param->img_stride[0];
> + param->dec_h = ds_row_h[0] * param->mcu_h;
> +
> + for (i = 0; i < MTK_JPEG_COMP_MAX; i++) {
> + /* They must be equal in frame mode. */
> + param->mem_stride[i] = param->img_stride[i];
> + param->comp_size[i] = param->mem_stride[i] * ds_row_h[i] *
> + param->mcu_h;
> + }
> +
> + param->y_size = param->comp_size[0];
> + param->uv_size = param->comp_size[1];
> + param->dec_size = param->y_size + (param->uv_size << 1);
> +
> + return 0;
> +}
> +
> +int mtk_jpeg_dec_fill_param(struct mtk_jpeg_dec_param *param)
> +{
> + if (mtk_jpeg_decide_format(param))
> + return -1;
> +
> + mtk_jpeg_calc_mcu(param);
> + mtk_jpeg_calc_dma_group(param);
> + if (mtk_jpeg_calc_dst_size(param))
> + return -2;
> +
> + return 0;
> +}
> +
> +u32 mtk_jpeg_dec_get_int_status(void __iomem *base)
> +{
> + u32 ret;
> +
> + ret = readl(base + JPGDEC_REG_INTERRUPT_STATUS) & BIT_INQST_MASK_ALLIRQ;
> + if (ret)
> + writel(ret, base + JPGDEC_REG_INTERRUPT_STATUS);
> +
> + return ret;
> +}
> +
> +u32 mtk_jpeg_dec_enum_result(u32 irq_result)
> +{
> + if (irq_result & BIT_INQST_MASK_EOF)
> + return MTK_JPEG_DEC_RESULT_EOF_DONE;
> + else if (irq_result & BIT_INQST_MASK_PAUSE)
> + return MTK_JPEG_DEC_RESULT_PAUSE;
> + else if (irq_result & BIT_INQST_MASK_UNDERFLOW)
> + return MTK_JPEG_DEC_RESULT_UNDERFLOW;
> + else if (irq_result & BIT_INQST_MASK_OVERFLOW)
> + return MTK_JPEG_DEC_RESULT_OVERFLOW;
> + else if (irq_result & BIT_INQST_MASK_ERROR_BS)
> + return MTK_JPEG_DEC_RESULT_ERROR_BS;
No need for 'else' here since the previous 'if' always returns if true.
> +
> + return MTK_JPEG_DEC_RESULT_ERROR_UNKNOWN;
> +}
> +
> +void mtk_jpeg_dec_start(void __iomem *base)
> +{
> + writel(0, base + JPGDEC_REG_TRIG);
> +}
> +
> +static void mtk_jpeg_dec_soft_reset(void __iomem *base)
> +{
> + writel(0x0000FFFF, base + JPGDEC_REG_INTERRUPT_STATUS);
> + writel(0x00, base + JPGDEC_REG_RESET);
> + writel(0x01, base + JPGDEC_REG_RESET);
> +}
> +
> +static void mtk_jpeg_dec_hard_reset(void __iomem *base)
> +{
> + writel(0x00, base + JPGDEC_REG_RESET);
> + writel(0x10, base + JPGDEC_REG_RESET);
> +}
> +
> +void mtk_jpeg_dec_reset(void __iomem *base)
> +{
> + mtk_jpeg_dec_soft_reset(base);
> + mtk_jpeg_dec_hard_reset(base);
> +}
> +
> +static void mtk_jpeg_dec_set_brz_factor(void __iomem *base, u8 yscale_w,
> + u8 yscale_h, u8 uvscale_w, u8 uvscale_h)
> +{
> + u32 val;
> +
> + val = (uvscale_h << 12) | (uvscale_w << 8) |
> + (yscale_h << 4) | yscale_w;
> + writel(val, base + JPGDEC_REG_BRZ_FACTOR);
> +}
> +
> +static void mtk_jpeg_dec_set_dst_bank0(void __iomem *base, u32 addr_y,
> + u32 addr_u, u32 addr_v)
> +{
> + mtk_jpeg_verify_align(addr_y, 16, JPGDEC_REG_DEST_ADDR0_Y);
> + writel(addr_y, base + JPGDEC_REG_DEST_ADDR0_Y);
> + mtk_jpeg_verify_align(addr_u, 16, JPGDEC_REG_DEST_ADDR0_U);
> + writel(addr_u, base + JPGDEC_REG_DEST_ADDR0_U);
> + mtk_jpeg_verify_align(addr_v, 16, JPGDEC_REG_DEST_ADDR0_V);
> + writel(addr_v, base + JPGDEC_REG_DEST_ADDR0_V);
> +}
> +
> +static void mtk_jpeg_dec_set_dst_bank1(void __iomem *base, u32 addr_y,
> + u32 addr_u, u32 addr_v)
> +{
> + writel(addr_y, base + JPGDEC_REG_DEST_ADDR1_Y);
> + writel(addr_u, base + JPGDEC_REG_DEST_ADDR1_U);
> + writel(addr_v, base + JPGDEC_REG_DEST_ADDR1_V);
> +}
> +
> +static void mtk_jpeg_dec_set_mem_stride(void __iomem *base, u32 stride_y,
> + u32 stride_uv)
> +{
> + writel((stride_y & 0xFFFF), base + JPGDEC_REG_STRIDE_Y);
> + writel((stride_uv & 0xFFFF), base + JPGDEC_REG_STRIDE_UV);
> +}
> +
> +static void mtk_jpeg_dec_set_img_stride(void __iomem *base, u32 stride_y,
> + u32 stride_uv)
> +{
> + writel((stride_y & 0xFFFF), base + JPGDEC_REG_IMG_STRIDE_Y);
> + writel((stride_uv & 0xFFFF), base + JPGDEC_REG_IMG_STRIDE_UV);
> +}
> +
> +static void mtk_jpeg_dec_set_pause_mcu_idx(void __iomem *base, u32 idx)
> +{
> + writel(idx & 0x0003FFFFFF, base + JPGDEC_REG_PAUSE_MCU_NUM);
> +}
> +
> +static void mtk_jpeg_dec_set_dec_mode(void __iomem *base, u32 mode)
> +{
> + writel(mode & 0x03, base + JPGDEC_REG_OPERATION_MODE);
> +}
> +
> +static void mtk_jpeg_dec_set_bs_write_ptr(void __iomem *base, u32 ptr)
> +{
> + mtk_jpeg_verify_align(ptr, 16, JPGDEC_REG_FILE_BRP);
> + writel(ptr, base + JPGDEC_REG_FILE_BRP);
> +}
> +
> +static void mtk_jpeg_dec_set_bs_info(void __iomem *base, u32 addr, u32 size)
> +{
> + mtk_jpeg_verify_align(addr, 16, JPGDEC_REG_FILE_ADDR);
> + mtk_jpeg_verify_align(size, 128, JPGDEC_REG_FILE_TOTAL_SIZE);
> + writel(addr, base + JPGDEC_REG_FILE_ADDR);
> + writel(size, base + JPGDEC_REG_FILE_TOTAL_SIZE);
> +}
> +
> +static void mtk_jpeg_dec_set_comp_id(void __iomem *base, u32 id_y, u32 id_u,
> + u32 id_v)
> +{
> + u32 val;
> +
> + val = ((id_y & 0x00FF) << 24) | ((id_u & 0x00FF) << 16) |
> + ((id_v & 0x00FF) << 8);
> + writel(val, base + JPGDEC_REG_COMP_ID);
> +}
> +
> +static void mtk_jpeg_dec_set_total_mcu(void __iomem *base, u32 num)
> +{
> + writel(num - 1, base + JPGDEC_REG_TOTAL_MCU_NUM);
> +}
> +
> +static void mtk_jpeg_dec_set_comp0_du(void __iomem *base, u32 num)
> +{
> + writel(num - 1, base + JPGDEC_REG_COMP0_DATA_UNIT_NUM);
> +}
> +
> +static void mtk_jpeg_dec_set_du_membership(void __iomem *base, u32 member,
> + u32 gmc, u32 isgray)
> +{
> + if (isgray)
> + member = 0x3FFFFFFC;
> + member |= (isgray << 31) | (gmc << 30);
> + writel(member, base + JPGDEC_REG_DU_CTRL);
> +}
> +
> +static void mtk_jpeg_dec_set_q_table(void __iomem *base, u32 id0, u32 id1,
> + u32 id2)
> +{
> + u32 val;
> +
> + val = ((id0 & 0x0f) << 8) | ((id1 & 0x0f) << 4) | ((id2 & 0x0f) << 0);
> + writel(val, base + JPGDEC_REG_QT_ID);
> +}
> +
> +static void mtk_jpeg_dec_set_dma_group(void __iomem *base, u32 mcu_group,
> + u32 group_num, u32 last_mcu)
> +{
> + u32 val;
> +
> + val = (((mcu_group - 1) & 0x00FF) << 16) |
> + (((group_num - 1) & 0x007F) << 8) |
> + ((last_mcu - 1) & 0x00FF);
> + writel(val, base + JPGDEC_REG_WDMA_CTRL);
> +}
> +
> +static void mtk_jpeg_dec_set_sampling_factor(void __iomem *base, u32 comp_num,
> + u32 y_w, u32 y_h, u32 u_w,
> + u32 u_h, u32 v_w, u32 v_h)
> +{
> + u32 val;
> + u32 y_wh = (MTK_JPEG_DUNUM_MASK(y_w) << 2) | MTK_JPEG_DUNUM_MASK(y_h);
> + u32 u_wh = (MTK_JPEG_DUNUM_MASK(u_w) << 2) | MTK_JPEG_DUNUM_MASK(u_h);
> + u32 v_wh = (MTK_JPEG_DUNUM_MASK(v_w) << 2) | MTK_JPEG_DUNUM_MASK(v_h);
> +
> + if (comp_num == 1)
> + val = 0;
> + else
> + val = (y_wh << 8) | (u_wh << 4) | v_wh;
> + writel(val, base + JPGDEC_REG_DU_NUM);
> +}
> +
> +void mtk_jpeg_dec_set_config(void __iomem *base,
> + struct mtk_jpeg_dec_param *config,
> + struct mtk_jpeg_bs *bs,
> + struct mtk_jpeg_fb *fb)
> +{
> + mtk_jpeg_dec_set_brz_factor(base, 0, 0, config->uv_brz_w, 0);
> + mtk_jpeg_dec_set_dec_mode(base, 0);
> + mtk_jpeg_dec_set_comp0_du(base, config->unit_num);
> + mtk_jpeg_dec_set_total_mcu(base, config->total_mcu);
> + mtk_jpeg_dec_set_bs_info(base, bs->str_addr, bs->size);
> + mtk_jpeg_dec_set_bs_write_ptr(base, bs->end_addr);
> + mtk_jpeg_dec_set_du_membership(base, config->membership, 1,
> + (config->comp_num == 1) ? 1 : 0);
> + mtk_jpeg_dec_set_comp_id(base, config->comp_id[0], config->comp_id[1],
> + config->comp_id[2]);
> + mtk_jpeg_dec_set_q_table(base, config->qtbl_num[0],
> + config->qtbl_num[1], config->qtbl_num[2]);
> + mtk_jpeg_dec_set_sampling_factor(base, config->comp_num,
> + config->sampling_w[0],
> + config->sampling_h[0],
> + config->sampling_w[1],
> + config->sampling_h[1],
> + config->sampling_w[2],
> + config->sampling_h[2]);
> + mtk_jpeg_dec_set_mem_stride(base, config->mem_stride[0],
> + config->mem_stride[1]);
> + mtk_jpeg_dec_set_img_stride(base, config->img_stride[0],
> + config->img_stride[1]);
> + mtk_jpeg_dec_set_dst_bank0(base, fb->plane_addr[0],
> + fb->plane_addr[1], fb->plane_addr[2]);
> + mtk_jpeg_dec_set_dst_bank1(base, 0, 0, 0);
> + mtk_jpeg_dec_set_dma_group(base, config->dma_mcu, config->dma_group,
> + config->dma_last_mcu);
> + mtk_jpeg_dec_set_pause_mcu_idx(base, config->total_mcu);
> +}
Regards,
Hans
--
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
* Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_simple_widgets" to the asoc tree
From: Mark Brown @ 2016-11-11 15:28 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Mark Brown, Rob Herring
In-Reply-To: <87lgxn4c4k.wl%kuninori.morimoto.gx@renesas.com>
The patch
ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_simple_widgets
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 1ef5bcd57be5c8b31286b7b47828064be25f266b Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date: Fri, 11 Nov 2016 01:18:08 +0000
Subject: [PATCH] ASoC: soc-core: adjust for graph on
snd_soc_of_parse_audio_simple_widgets
It is assuming that the card related information is located on
"card" node, but graph case doesn't have it.
This patch adds node parameter to adjust for graph support
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
include/sound/soc.h | 8 ++++++--
sound/soc/soc-core.c | 9 ++++++---
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 8457aab9eab0..77b01c45ee8d 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1647,8 +1647,12 @@ void snd_soc_util_exit(void);
int snd_soc_of_parse_card_name_from_node(struct snd_soc_card *card,
struct device_node *np,
const char *propname);
-int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
- const char *propname);
+#define snd_soc_of_parse_audio_simple_widgets(card, propname)\
+ snd_soc_of_parse_audio_simple_widgets_from_node(card, NULL, propname)
+int snd_soc_of_parse_audio_simple_widgets_from_node(struct snd_soc_card *card,
+ struct device_node *np,
+ const char *propname);
+
int snd_soc_of_parse_tdm_slot(struct device_node *np,
unsigned int *tx_mask,
unsigned int *rx_mask,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 17132fb57930..6f911f4d413a 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3462,14 +3462,17 @@ static const struct snd_soc_dapm_widget simple_widgets[] = {
SND_SOC_DAPM_SPK("Speaker", NULL),
};
-int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
+int snd_soc_of_parse_audio_simple_widgets_from_node(struct snd_soc_card *card,
+ struct device_node *np,
const char *propname)
{
- struct device_node *np = card->dev->of_node;
struct snd_soc_dapm_widget *widgets;
const char *template, *wname;
int i, j, num_widgets, ret;
+ if (!np)
+ np = card->dev->of_node;
+
num_widgets = of_property_count_strings(np, propname);
if (num_widgets < 0) {
dev_err(card->dev,
@@ -3540,7 +3543,7 @@ int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
return 0;
}
-EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_simple_widgets);
+EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_simple_widgets_from_node);
static int snd_soc_of_get_slot_mask(struct device_node *np,
const char *prop_name,
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_card_name" to the asoc tree
From: Mark Brown @ 2016-11-11 15:28 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Mark Brown, Rob Herring
In-Reply-To: <87mvi34c51.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
The patch
ASoC: soc-core: adjust for graph on snd_soc_of_parse_card_name
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 8f5ebb1bee15b5720741a98414767bb86f6c2b23 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Date: Fri, 11 Nov 2016 01:17:27 +0000
Subject: [PATCH] ASoC: soc-core: adjust for graph on
snd_soc_of_parse_card_name
It is assuming that the card related information is located on
"card" node, but graph case doesn't have it.
This patch adds node parameter to adjust for graph support
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
include/sound/soc.h | 7 +++++--
sound/soc/soc-core.c | 11 ++++++-----
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 346223b38e0d..8457aab9eab0 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1642,8 +1642,11 @@ static inline struct snd_soc_platform *snd_soc_kcontrol_platform(
int snd_soc_util_init(void);
void snd_soc_util_exit(void);
-int snd_soc_of_parse_card_name(struct snd_soc_card *card,
- const char *propname);
+#define snd_soc_of_parse_card_name(card, propname) \
+ snd_soc_of_parse_card_name_from_node(card, NULL, propname)
+int snd_soc_of_parse_card_name_from_node(struct snd_soc_card *card,
+ struct device_node *np,
+ const char *propname);
int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
const char *propname);
int snd_soc_of_parse_tdm_slot(struct device_node *np,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index e4c90806fa10..17132fb57930 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3424,10 +3424,10 @@ void snd_soc_unregister_codec(struct device *dev)
EXPORT_SYMBOL_GPL(snd_soc_unregister_codec);
/* Retrieve a card's name from device tree */
-int snd_soc_of_parse_card_name(struct snd_soc_card *card,
- const char *propname)
+int snd_soc_of_parse_card_name_from_node(struct snd_soc_card *card,
+ struct device_node *np,
+ const char *propname)
{
- struct device_node *np;
int ret;
if (!card->dev) {
@@ -3435,7 +3435,8 @@ int snd_soc_of_parse_card_name(struct snd_soc_card *card,
return -EINVAL;
}
- np = card->dev->of_node;
+ if (!np)
+ np = card->dev->of_node;
ret = of_property_read_string_index(np, propname, 0, &card->name);
/*
@@ -3452,7 +3453,7 @@ int snd_soc_of_parse_card_name(struct snd_soc_card *card,
return 0;
}
-EXPORT_SYMBOL_GPL(snd_soc_of_parse_card_name);
+EXPORT_SYMBOL_GPL(snd_soc_of_parse_card_name_from_node);
static const struct snd_soc_dapm_widget simple_widgets[] = {
SND_SOC_DAPM_MIC("Microphone", NULL),
--
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
* Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_prefix" to the asoc tree
From: Mark Brown @ 2016-11-11 15:28 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Mark Brown, Rob Herring
In-Reply-To: <87insr4c3i.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
The patch
ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_prefix
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From b6defcca0a604129155ae472b116a2e1688d8995 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Date: Fri, 11 Nov 2016 01:19:03 +0000
Subject: [PATCH] ASoC: soc-core: adjust for graph on
snd_soc_of_parse_audio_prefix
It is assuming that the card related information is located on
"card" node, but graph case doesn't have it.
This patch adds node parameter to adjust for graph support
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
include/sound/soc.h | 6 +++++-
sound/soc/soc-core.c | 9 ++++++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 6dffa9540a30..346223b38e0d 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1651,7 +1651,11 @@ int snd_soc_of_parse_tdm_slot(struct device_node *np,
unsigned int *rx_mask,
unsigned int *slots,
unsigned int *slot_width);
-void snd_soc_of_parse_audio_prefix(struct snd_soc_card *card,
+#define snd_soc_of_parse_audio_prefix(card, codec_conf, of_node, propname) \
+ snd_soc_of_parse_audio_prefix_from_node(card, NULL, codec_conf, \
+ of_node, propname)
+void snd_soc_of_parse_audio_prefix_from_node(struct snd_soc_card *card,
+ struct device_node *np,
struct snd_soc_codec_conf *codec_conf,
struct device_node *of_node,
const char *propname);
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 81b604151f26..e4c90806fa10 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3595,15 +3595,18 @@ int snd_soc_of_parse_tdm_slot(struct device_node *np,
}
EXPORT_SYMBOL_GPL(snd_soc_of_parse_tdm_slot);
-void snd_soc_of_parse_audio_prefix(struct snd_soc_card *card,
+void snd_soc_of_parse_audio_prefix_from_node(struct snd_soc_card *card,
+ struct device_node *np,
struct snd_soc_codec_conf *codec_conf,
struct device_node *of_node,
const char *propname)
{
- struct device_node *np = card->dev->of_node;
const char *str;
int ret;
+ if (!np)
+ np = card->dev->of_node;
+
ret = of_property_read_string(np, propname, &str);
if (ret < 0) {
/* no prefix is not error */
@@ -3613,7 +3616,7 @@ void snd_soc_of_parse_audio_prefix(struct snd_soc_card *card,
codec_conf->of_node = of_node;
codec_conf->name_prefix = str;
}
-EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_prefix);
+EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_prefix_from_node);
int snd_soc_of_parse_audio_routing_from_node(struct snd_soc_card *card,
struct device_node *np,
--
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
* Applied "ASoC: soc-core: snd_soc_get_dai_name() become non static" to the asoc tree
From: Mark Brown @ 2016-11-11 15:28 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Mark Brown, Rob Herring
In-Reply-To: <87h98b4c30.wl%kuninori.morimoto.gx@renesas.com>
The patch
ASoC: soc-core: snd_soc_get_dai_name() become non static
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 1ad8ec535b997ed36c0f32c2616206725258dd30 Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date: Fri, 11 Nov 2016 01:19:28 +0000
Subject: [PATCH] ASoC: soc-core: snd_soc_get_dai_name() become non static
snd_soc_get_dai_name() is used from snd_soc_of_get_dai_name(),
and it is assuming that DT is using "sound-dai" / "#sound-dai-cells".
But graph base DT is using "remote-endpoint". This patch makes
snd_soc_get_dai_name() non static for graph support.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
include/sound/soc.h | 2 ++
sound/soc/soc-core.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 148bf553d598..6dffa9540a30 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1666,6 +1666,8 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
const char *prefix,
struct device_node **bitclkmaster,
struct device_node **framemaster);
+int snd_soc_get_dai_name(struct of_phandle_args *args,
+ const char **dai_name);
int snd_soc_of_get_dai_name(struct device_node *of_node,
const char **dai_name);
int snd_soc_of_get_dai_link_codecs(struct device *dev,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index ec881b8825b6..81b604151f26 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3787,7 +3787,7 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
}
EXPORT_SYMBOL_GPL(snd_soc_of_parse_daifmt);
-static int snd_soc_get_dai_name(struct of_phandle_args *args,
+int snd_soc_get_dai_name(struct of_phandle_args *args,
const char **dai_name)
{
struct snd_soc_component *pos;
@@ -3839,6 +3839,7 @@ static int snd_soc_get_dai_name(struct of_phandle_args *args,
mutex_unlock(&client_mutex);
return ret;
}
+EXPORT_SYMBOL_GPL(snd_soc_get_dai_name);
int snd_soc_of_get_dai_name(struct device_node *of_node,
const char **dai_name)
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_routing" to the asoc tree
From: Mark Brown @ 2016-11-11 15:29 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Mark Brown, Rob Herring
In-Reply-To: <87k2d74c43.wl%kuninori.morimoto.gx@renesas.com>
The patch
ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_routing
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7364c8dc255232db33bcd1c5b19eb8f34cf6108a Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date: Fri, 11 Nov 2016 01:18:35 +0000
Subject: [PATCH] ASoC: soc-core: adjust for graph on
snd_soc_of_parse_audio_routing
It is assuming that the card related information is located on
"card" node, but graph case doesn't have it.
This patch adds node parameter to adjust for graph support
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
include/sound/soc.h | 9 +++++++--
sound/soc/soc-core.c | 9 ++++++---
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 4f1c784e44f6..148bf553d598 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1655,8 +1655,13 @@ void snd_soc_of_parse_audio_prefix(struct snd_soc_card *card,
struct snd_soc_codec_conf *codec_conf,
struct device_node *of_node,
const char *propname);
-int snd_soc_of_parse_audio_routing(struct snd_soc_card *card,
- const char *propname);
+
+#define snd_soc_of_parse_audio_routing(card, propname) \
+ snd_soc_of_parse_audio_routing_from_node(card, NULL, propname)
+int snd_soc_of_parse_audio_routing_from_node(struct snd_soc_card *card,
+ struct device_node *np,
+ const char *propname);
+
unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
const char *prefix,
struct device_node **bitclkmaster,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index c0bbcd903261..ec881b8825b6 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3615,14 +3615,17 @@ void snd_soc_of_parse_audio_prefix(struct snd_soc_card *card,
}
EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_prefix);
-int snd_soc_of_parse_audio_routing(struct snd_soc_card *card,
+int snd_soc_of_parse_audio_routing_from_node(struct snd_soc_card *card,
+ struct device_node *np,
const char *propname)
{
- struct device_node *np = card->dev->of_node;
int num_routes;
struct snd_soc_dapm_route *routes;
int i, ret;
+ if (!np)
+ np = card->dev->of_node;
+
num_routes = of_property_count_strings(np, propname);
if (num_routes < 0 || num_routes & 1) {
dev_err(card->dev,
@@ -3669,7 +3672,7 @@ int snd_soc_of_parse_audio_routing(struct snd_soc_card *card,
return 0;
}
-EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_routing);
+EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_routing_from_node);
unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
const char *prefix,
--
2.10.2
^ permalink raw reply related
* RE: [PATCH V2 05/10] mfd: da9061: MFD core support
From: Steve Twiss @ 2016-11-11 15:50 UTC (permalink / raw)
To: Lee Jones
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <20161111103734.GD13638@dell>
On 11 November 2016 10:38, Lee Jones wrote:
>
> > +static struct resource da9061_core_resources[] = {
> > + DEFINE_RES_NAMED(DA9061_IRQ_VDD_WARN, 1, "VDD_WARN", IORESOURCE_IRQ),
> > +};
> > +
> > +static struct resource da9061_regulators_resources[] = {
> > + DEFINE_RES_NAMED(DA9061_IRQ_LDO_LIM, 1, "LDO_LIM", IORESOURCE_IRQ),
> > +};
> > +
> > +static struct resource da9061_thermal_resources[] = {
> > + DEFINE_RES_NAMED(DA9061_IRQ_TEMP, 1, "THERMAL", IORESOURCE_IRQ),
> > +};
> > +
> > +static struct resource da9061_wdt_resources[] = {
> > + DEFINE_RES_NAMED(DA9061_IRQ_WDG_WARN, 1, "WD_WARN", IORESOURCE_IRQ),
> > +};
> > +
> > +static struct resource da9061_onkey_resources[] = {
> > + DEFINE_RES_NAMED(DA9061_IRQ_ONKEY, 1, "ONKEY", IORESOURCE_IRQ),
> > +};
>
> These should al be: DEFINE_RES_IO_NAMED()
Have altered these to DEFINE_RES_IRQ_NAMED()
> > @@ -142,7 +257,7 @@ static const struct mfd_cell da9062_devs[] = {
> > .name = "da9062-watchdog",
> > .num_resources = ARRAY_SIZE(da9062_wdt_resources),
> > .resources = da9062_wdt_resources,
> > - .of_compatible = "dlg,da9062-wdt",
> > + .of_compatible = "dlg,da9062-watchdog",
>
> This should be a separate change.
Ok. reverted.
> > @@ -208,6 +324,7 @@ static int da9062_get_device_type(struct da9062 *chip)
> > dev_err(chip->dev, "Cannot read chip ID.\n");
> > return -EIO;
> > }
> > +
>
> Sneaky!
Removed the whitespace.
^ permalink raw reply
* [PATCH 1/3] powerpc/fsl/dts: add QMan and BMan portal nodes on t1023rdb
From: Madalin Bucur @ 2016-11-11 15:53 UTC (permalink / raw)
To: devicetree; +Cc: oss, linuxppc-dev
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/boot/dts/fsl/t1023rdb.dts | 27 ++++++++
arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 103 ++++++++++++++++++++++++++++
2 files changed, 130 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1023rdb.dts b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
index 2975762..24c9de3 100644
--- a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
@@ -41,6 +41,25 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ };
+ qman_fqd: qman-fqd {
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ };
+ qman_pfdr: qman-pfdr {
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ };
+ };
+
ifc: localbus@ffe124000 {
reg = <0xf 0xfe124000 0 0x2000>;
ranges = <0 0 0xf 0xe8000000 0x08000000
@@ -72,6 +91,14 @@
ranges = <0x00000000 0xf 0x00000000 0x01072000>;
};
+ bportals: bman-portals@ff4000000 {
+ ranges = <0x0 0xf 0xf4000000 0x2000000>;
+ };
+
+ qportals: qman-portals@ff6000000 {
+ ranges = <0x0 0xf 0xf6000000 0x2000000>;
+ };
+
soc: soc@ffe000000 {
ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
reg = <0xf 0xfe000000 0 0x00001000>;
diff --git a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
index 6e0b489..da2894c 100644
--- a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
@@ -34,6 +34,21 @@
#include <dt-bindings/thermal/thermal.h>
+&bman_fbpr {
+ compatible = "fsl,bman-fbpr";
+ alloc-ranges = <0 0 0x10000 0>;
+};
+
+&qman_fqd {
+ compatible = "fsl,qman-fqd";
+ alloc-ranges = <0 0 0x10000 0>;
+};
+
+&qman_pfdr {
+ compatible = "fsl,qman-pfdr";
+ alloc-ranges = <0 0 0x10000 0>;
+};
+
&ifc {
#address-cells = <2>;
#size-cells = <1>;
@@ -180,6 +195,92 @@
};
};
+&bportals {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "simple-bus";
+
+ bman-portal@0 {
+ cell-index = <0x0>;
+ compatible = "fsl,bman-portal";
+ reg = <0x0 0x4000>, <0x1000000 0x1000>;
+ interrupts = <105 2 0 0>;
+ };
+ bman-portal@4000 {
+ cell-index = <0x1>;
+ compatible = "fsl,bman-portal";
+ reg = <0x4000 0x4000>, <0x1001000 0x1000>;
+ interrupts = <107 2 0 0>;
+ };
+ bman-portal@8000 {
+ cell-index = <2>;
+ compatible = "fsl,bman-portal";
+ reg = <0x8000 0x4000>, <0x1002000 0x1000>;
+ interrupts = <109 2 0 0>;
+ };
+ bman-portal@c000 {
+ cell-index = <0x3>;
+ compatible = "fsl,bman-portal";
+ reg = <0xc000 0x4000>, <0x1003000 0x1000>;
+ interrupts = <111 2 0 0>;
+ };
+ bman-portal@10000 {
+ cell-index = <0x4>;
+ compatible = "fsl,bman-portal";
+ reg = <0x10000 0x4000>, <0x1004000 0x1000>;
+ interrupts = <113 2 0 0>;
+ };
+ bman-portal@14000 {
+ cell-index = <0x5>;
+ compatible = "fsl,bman-portal";
+ reg = <0x14000 0x4000>, <0x1005000 0x1000>;
+ interrupts = <115 2 0 0>;
+ };
+};
+
+&qportals {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "simple-bus";
+
+ qportal0: qman-portal@0 {
+ compatible = "fsl,qman-portal";
+ reg = <0x0 0x4000>, <0x1000000 0x1000>;
+ interrupts = <104 0x2 0 0>;
+ cell-index = <0x0>;
+ };
+ qportal1: qman-portal@4000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x4000 0x4000>, <0x1001000 0x1000>;
+ interrupts = <106 0x2 0 0>;
+ cell-index = <0x1>;
+ };
+ qportal2: qman-portal@8000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x8000 0x4000>, <0x1002000 0x1000>;
+ interrupts = <108 0x2 0 0>;
+ cell-index = <0x2>;
+ };
+ qportal3: qman-portal@c000 {
+ compatible = "fsl,qman-portal";
+ reg = <0xc000 0x4000>, <0x1003000 0x1000>;
+ interrupts = <110 0x2 0 0>;
+ cell-index = <0x3>;
+ };
+ qportal4: qman-portal@10000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x10000 0x4000>, <0x1004000 0x1000>;
+ interrupts = <112 0x2 0 0>;
+ cell-index = <0x4>;
+ };
+ qportal5: qman-portal@14000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x14000 0x4000>, <0x1005000 0x1000>;
+ interrupts = <114 0x2 0 0>;
+ cell-index = <0x5>;
+ };
+};
+
&soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -413,6 +514,8 @@
};
/include/ "qoriq-sec5.0-0.dtsi"
+/include/ "qoriq-qman3.dtsi"
+/include/ "qoriq-bman1.dtsi"
/include/ "qoriq-fman3l-0.dtsi"
/include/ "qoriq-fman3-0-10g-0-best-effort.dtsi"
--
2.1.0
^ permalink raw reply related
* [PATCH 2/3] powerpc/fsl/dts: add QMan and BMan portal nodes on t1024
From: Madalin Bucur @ 2016-11-11 15:53 UTC (permalink / raw)
To: devicetree; +Cc: oss, linuxppc-dev
In-Reply-To: <1478879598-3362-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/boot/dts/fsl/t1024qds.dts | 27 +++++++++++++++++++++++++++
arch/powerpc/boot/dts/fsl/t1024rdb.dts | 31 +++++++++++++++++++++++++++++++
2 files changed, 58 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1024qds.dts b/arch/powerpc/boot/dts/fsl/t1024qds.dts
index 772143d..339517e 100644
--- a/arch/powerpc/boot/dts/fsl/t1024qds.dts
+++ b/arch/powerpc/boot/dts/fsl/t1024qds.dts
@@ -41,6 +41,25 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ };
+ qman_fqd: qman-fqd {
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ };
+ qman_pfdr: qman-pfdr {
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ };
+ };
+
ifc: localbus@ffe124000 {
reg = <0xf 0xfe124000 0 0x2000>;
ranges = <0 0 0xf 0xe8000000 0x08000000
@@ -80,6 +99,14 @@
ranges = <0x00000000 0xf 0x00000000 0x01072000>;
};
+ bportals: bman-portals@ff4000000 {
+ ranges = <0x0 0xf 0xf4000000 0x2000000>;
+ };
+
+ qportals: qman-portals@ff6000000 {
+ ranges = <0x0 0xf 0xf6000000 0x2000000>;
+ };
+
soc: soc@ffe000000 {
ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
reg = <0xf 0xfe000000 0 0x00001000>;
diff --git a/arch/powerpc/boot/dts/fsl/t1024rdb.dts b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
index 302cdd2..2656095 100644
--- a/arch/powerpc/boot/dts/fsl/t1024rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
@@ -41,6 +41,29 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
+ aliases {
+ sg_2500_aqr105_phy4 = &sg_2500_aqr105_phy4;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ };
+ qman_fqd: qman-fqd {
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ };
+ qman_pfdr: qman-pfdr {
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ };
+ };
+
ifc: localbus@ffe124000 {
reg = <0xf 0xfe124000 0 0x2000>;
ranges = <0 0 0xf 0xe8000000 0x08000000
@@ -82,6 +105,14 @@
ranges = <0x00000000 0xf 0x00000000 0x01072000>;
};
+ bportals: bman-portals@ff4000000 {
+ ranges = <0x0 0xf 0xf4000000 0x2000000>;
+ };
+
+ qportals: qman-portals@ff6000000 {
+ ranges = <0x0 0xf 0xf6000000 0x2000000>;
+ };
+
soc: soc@ffe000000 {
ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
reg = <0xf 0xfe000000 0 0x00001000>;
--
2.1.0
^ permalink raw reply related
* [PATCH 3/3] powerpc/fsl/dts: add FMan node for t1042d4rdb
From: Madalin Bucur @ 2016-11-11 15:53 UTC (permalink / raw)
To: devicetree; +Cc: oss, linuxppc-dev
In-Reply-To: <1478879598-3362-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/boot/dts/fsl/t1042d4rdb.dts | 47 ++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts b/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts
index 2a5a90d..8c0c318 100644
--- a/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts
@@ -48,6 +48,53 @@
"fsl,deepsleep-cpld";
};
};
+ soc: soc@ffe000000 {
+ fman0: fman@400000 {
+ ethernet@e0000 {
+ phy-handle = <&phy_sgmii_0>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@e2000 {
+ phy-handle = <&phy_sgmii_1>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@e4000 {
+ phy-handle = <&phy_sgmii_2>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@e6000 {
+ phy-handle = <&phy_rgmii_0>;
+ phy-connection-type = "rgmii";
+ };
+
+ ethernet@e8000 {
+ phy-handle = <&phy_rgmii_1>;
+ phy-connection-type = "rgmii";
+ };
+
+ mdio0: mdio@fc000 {
+ phy_sgmii_0: ethernet-phy@02 {
+ reg = <0x02>;
+ };
+ phy_sgmii_1: ethernet-phy@03 {
+ reg = <0x03>;
+ };
+ phy_sgmii_2: ethernet-phy@01 {
+ reg = <0x01>;
+ };
+ phy_rgmii_0: ethernet-phy@04 {
+ reg = <0x04>;
+ };
+ phy_rgmii_1: ethernet-phy@05 {
+ reg = <0x05>;
+ };
+ };
+ };
+ };
+
};
#include "t1042si-post.dtsi"
--
2.1.0
^ permalink raw reply related
* RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-11 15:53 UTC (permalink / raw)
To: liviu.dudau@arm.com
Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org, Yuanzhichang,
mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, minyard@acm.org,
linux-pci@vger.kernel.org, benh@kernel.crashing.org, John Garry,
will.deacon@arm.com, linux-kernel@vger.kernel.org, xuwei (O),
Linuxarm, zourongrong@gmail.com, robh+dt@kernel.org
In-Reply-To: <20161111144539.GL10219@e106497-lin.cambridge.arm.com>
Hi Liviu
> -----Original Message-----
> From: liviu.dudau@arm.com [mailto:liviu.dudau@arm.com]
> Sent: 11 November 2016 14:46
> To: Gabriele Paoloni
> Cc: Arnd Bergmann; linux-arm-kernel@lists.infradead.org; Yuanzhichang;
> mark.rutland@arm.com; devicetree@vger.kernel.org;
> lorenzo.pieralisi@arm.com; minyard@acm.org; linux-pci@vger.kernel.org;
> benh@kernel.crashing.org; John Garry; will.deacon@arm.com; linux-
> kernel@vger.kernel.org; xuwei (O); Linuxarm; zourongrong@gmail.com;
> robh+dt@kernel.org; kantyzc@163.com; linux-serial@vger.kernel.org;
> catalin.marinas@arm.com; olof@lixom.net; bhelgaas@googl e.com;
> zhichang.yuan02@gmail.com
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Fri, Nov 11, 2016 at 01:39:35PM +0000, Gabriele Paoloni wrote:
> > Hi Arnd
> >
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > Sent: 10 November 2016 16:07
> > > To: Gabriele Paoloni
> > > Cc: linux-arm-kernel@lists.infradead.org; Yuanzhichang;
> > > mark.rutland@arm.com; devicetree@vger.kernel.org;
> > > lorenzo.pieralisi@arm.com; minyard@acm.org; linux-
> pci@vger.kernel.org;
> > > benh@kernel.crashing.org; John Garry; will.deacon@arm.com; linux-
> > > kernel@vger.kernel.org; xuwei (O); Linuxarm; zourongrong@gmail.com;
> > > robh+dt@kernel.org; kantyzc@163.com; linux-serial@vger.kernel.org;
> > > catalin.marinas@arm.com; olof@lixom.net; liviu.dudau@arm.com;
> > > bhelgaas@googl e.com; zhichang.yuan02@gmail.com
> > > Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> > > Hip06
> > >
> > > On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni
> wrote:
> > > >
> > > > Where should we get the range from? For LPC we know that it is
> going
> > > > Work on anything that is not used by PCI I/O space, and this is
> > > > why we use [0, PCIBIOS_MIN_IO]
> > >
> > > It should be allocated the same way we allocate PCI config space
> > > segments. This is currently done with the io_range list in
> > > drivers/pci/pci.c, which isn't perfect but could be extended
> > > if necessary. Based on what others commented here, I'd rather
> > > make the differences between ISA/LPC and PCI I/O ranges smaller
> > > than larger.
>
> Gabriele,
>
> >
> > I am not sure this would make sense...
> >
> > IMHO all the mechanism around io_range_list is needed to provide the
> > "mapping" between I/O tokens and physical CPU addresses.
> >
> > Currently the available tokens range from 0 to IO_SPACE_LIMIT.
> >
> > As you know the I/O memory accessors operate on whatever
> > __of_address_to_resource sets into the resource (start, end).
> >
> > With this special device in place we cannot know if a resource is
> > assigned with an I/O token or a physical address, unless we forbid
> > the I/O tokens to be in a specific range.
> >
> > So this is why we are changing the offsets of all the functions
> > handling io_range_list (to make sure that a range is forbidden to
> > the tokens and is available to the physical addresses).
> >
> > We have chosen this forbidden range to be [0, PCIBIOS_MIN_IO)
> > because this is the maximum physical I/O range that a non PCI device
> > can operate on and because we believe this does not impose much
> > restriction on the available I/O token range; that now is
> > [PCIBIOS_MIN_IO, IO_SPACE_LIMIT].
> > So we believe that the chosen forbidden range can accommodate
> > any special ISA bus device with no much constraint on the rest
> > of I/O tokens...
>
> Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and you
> actually need another variable for "reserving" an area in the I/O space
> that can be used for physical addresses rather than I/O tokens.
>
> The one good example for using PCIBIOS_MIN_IO is when your
> platform/architecture
> does not support legacy ISA operations *at all*. In that case someone
> sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O range
> so that it doesn't get used. With Zhichang's patch you now start
> forcing
> those platforms to have a valid address below PCIBIOS_MIN_IO.
But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be used
by PCI controllers only...so if you have a special bus device using
an I/O range in this case should be a PCI controller...i.e. I would
expect it to fall back into the case of I/O tokens redirection rather than
physical addresses redirection (as mentioned below from my previous reply).
What do you think?
Thanks
Gab
>
> For the general case you also have to bear in mind that PCIBIOS_MIN_IO
> could
> be zero. In that case, what is your "forbidden" range? [0, 0) ? So it
> makes
> sense to add a new #define that should only be defined by those
> architectures/
> platforms that want to reserve on top of PCIBIOS_MIN_IO another region
> where I/O tokens can't be generated for.
>
> Best regards,
> Liviu
>
> >
> > >
> > > > > Your current version has
> > > > >
> > > > > if (arm64_extio_ops->pfout)
> \
> > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> >devpara,\
> > > > > addr, value, sizeof(type));
> \
> > > > >
> > > > > Instead, just subtract the start of the range from the logical
> > > > > port number to transform it back into a bus-local port number:
> > > >
> > > > These accessors do not operate on IO tokens:
> > > >
> > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
> > > > addr is not going to be an I/O token; in fact patch 2/3 imposes
> that
> > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > PCIBIOS_MIN_IO
> > > > we have free physical addresses that the accessors can operate
> on.
> > >
> > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer
> to
> > > the logical I/O tokens, the purpose of that macro is really meant
> > > for allocating PCI I/O port numbers within the address space of
> > > one bus.
> >
> > As I mentioned above, special devices operate on CPU addresses
> directly,
> > not I/O tokens. For them there is no way to distinguish....
> >
> > >
> > > Note that it's equally likely that whichever next platform needs
> > > non-mapped I/O access like this actually needs them for PCI I/O
> space,
> > > and that will use it on addresses registered to a PCI host bridge.
> >
> > Ok so here you are talking about a platform that has got an I/O range
> > under the PCI host controller, right?
> > And this I/O range cannot be directly memory mapped but needs special
> > redirections for the I/O tokens, right?
> >
> > In this scenario registering the I/O ranges with the forbidden range
> > implemented by the current patch would still allow to redirect I/O
> > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> >
> > So effectively the special PCI host controller
> > 1) knows the physical range that needs special redirection
> > 2) register such range
> > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > special accessors
> > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in 3)
> >
> > So to be honest I think this patch can fit well both with
> > special PCI controllers that need I/O tokens redirection and with
> > special non-PCI controllers that need non-PCI I/O physical
> > address redirection...
> >
> > Thanks (and sorry for the long reply but I didn't know how
> > to make the explanation shorter :) )
> >
> > Gab
> >
> > >
> > > If we separate the two steps:
> > >
> > > a) assign a range of logical I/O port numbers to a bus
> > > b) register a set of helpers for redirecting logical I/O
> > > port to a helper function
> > >
> > > then I think the code will get cleaner and more flexible.
> > > It should actually then be able to replace the powerpc
> > > specific implementation.
> > >
> > > Arnd
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6q-cm-fx6: fix fec pinctrl
From: christopher.spinrath @ 2016-11-11 15:59 UTC (permalink / raw)
To: shawnguo, kernel
Cc: mark.rutland, devicetree, Christopher Spinrath, linux, robh+dt,
grinberg, fabio.estevam, linux-arm-kernel
From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
According to the schematics of CompuLab's sbc-fx6 baseboard and the
vendor devicetree GPIO_16 is *not* muxed to ENET_REF_CLK but to SPDIF_IN.
Remove the wrong pinctrl setting.
Fixes: 682d055e6ac5 ("ARM: dts: Add initial support for cm-fx6.")
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
---
arch/arm/boot/dts/imx6q-cm-fx6.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
index 59bc5a4..a150bca 100644
--- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
+++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
@@ -183,7 +183,6 @@
MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
- MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
>;
};
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: imx6q-utilite-pro: i2c1 is muxed
From: christopher.spinrath @ 2016-11-11 15:59 UTC (permalink / raw)
To: shawnguo, kernel
Cc: mark.rutland, devicetree, Christopher Spinrath, linux, robh+dt,
grinberg, fabio.estevam, linux-arm-kernel
In-Reply-To: <20161111155939.446-1-christopher.spinrath@rwth-aachen.de>
From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
It turns out that the i2c1 adapter is connected to a multiplexer
controlled by a gpio line. The first (default) mux option connects
i2c1 to a bus connected to the already known peripherals. The other
one connects the adapter to the ddc pins of the DVI port.
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
---
arch/arm/boot/dts/imx6q-utilite-pro.dts | 51 ++++++++++++++++++++++++++-------
1 file changed, 40 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
index 6199063..246979a 100644
--- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
+++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
@@ -71,6 +71,40 @@
gpio-key,wakeup;
};
};
+
+ i2cmux {
+ compatible = "i2c-mux-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1mux>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mux-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ i2c-parent = <&i2c1>;
+
+ i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eeprom@50 {
+ compatible = "at24,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+
+ em3027: rtc@56 {
+ compatible = "emmicro,em3027";
+ reg = <0x56>;
+ };
+ };
+
+ i2c_dvi_ddc: i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
};
&hdmi {
@@ -82,17 +116,6 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
-
- eeprom@50 {
- compatible = "at24,24c02";
- reg = <0x50>;
- pagesize = <16>;
- };
-
- em3027: rtc@56 {
- compatible = "emmicro,em3027";
- reg = <0x56>;
- };
};
&i2c2 {
@@ -115,6 +138,12 @@
>;
};
+ pinctrl_i2c1mux: i2c1muxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ >;
+ };
+
pinctrl_i2c2: i2c2grp {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v8] mtd: nand: add tango NAND flash controller support
From: Mason @ 2016-11-11 16:01 UTC (permalink / raw)
To: Boris Brezillon
Cc: Marc Gonzalez, linux-mtd, Richard Weinberger, DT, Rob Herring,
Mark Rutland, Sebastian Frias
In-Reply-To: <20161106235812.0bcbbdc5@bbrezillon>
On 06/11/2016 23:58, Boris Brezillon wrote:
> Applied after fixing a few coding style issues to make checkpatch happy.
First of all, I want to thank you for all the help you provided
along the way.
I have to admit that I'm a bit frustrated by some of the changes you made
to the patch.
Specifically, changing
from: if (ptr_expr == NULL)
to: if (!ptr_expr)
I dislike the second form, because it "hides" what is being tested.
I've even seen people use !count to mean count == 0, and I find that
very unintuitive.
I also have a hard time discerning a '!' after a '('
The other change is the chip->options initialization. I thought
you said on IRC I could keep my preferred formatting.
In the end, these are tiny issues in the grand scheme of things,
but it was important for me to point them out.
Regards.
--
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 1/3] ASoC: atmel_ssc_dai: if not provided, default to sensible dividers
From: Mark Brown @ 2016-11-11 16:05 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood, Rob Herring,
Mark Rutland, Nicolas Ferre, Jaroslav Kysela, Takashi Iwai,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478863752-10569-2-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
On Fri, Nov 11, 2016 at 12:29:10PM +0100, Peter Rosin wrote:
> When this driver masters BCLK and/or LRCLK, and noone has stated
> differently, assume that all the bits of a frame are used.
>
> This relieves the cpu dai users from the duty to fill in the dividers for
> the common case.
This looks good and like what I was meaning with my earlier feedback
(you sent a new version before I could reply to that). I'll leave this
for a little while to give others time to review though.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox