From: Jacek Anaszewski <j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
To: Tony K Nadackal <tony.kn-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org,
kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
k.debski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
bhushan.r-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
Subject: Re: [PATCH] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support
Date: Wed, 07 Jan 2015 13:39:25 +0100 [thread overview]
Message-ID: <54AD28FD.4020703@samsung.com> (raw)
In-Reply-To: <000a01d02a72$bc6e06b0$354a1410$@samsung.com>
Hi Tony,
On 01/07/2015 01:08 PM, Tony K Nadackal wrote:
> Dear Jacek,
>
> On Wednesday, January 07, 2015 3:15 PM Jacek Anaszewski wrote,
>
>> Hi Tony,
>>
>> Sorry for late response, just got back from vacation.
>>
>> On 12/19/2014 04:37 AM, Tony K Nadackal wrote:
>>> Hi Jacek,
>>>
>>> On Wednesday, December 17, 2014 7:46 PM Jacek Anaszewski wrote,
>>>> Hi Tony,
>>>>
>>>> Thanks for the patches.
>>>>
>>>
>>> Thanks for the review.
>>>
>>>> Please process them with scripts/checkpatch.pl as you will be
>>>> submitting the
>>> next
>>>> version - they contain many coding style related issues.
>>>>
>>>
>>> I ran checkpatch before posting. Do you find any checkpatch related
>>> issues in the patch?
>>
>> There was a problem on my side, sorry for making confusion.
>>
>>>> My remaining comments below.
>>>>
>>>
>>> [snip]
>>>
>>>>> + if (ctx->jpeg->variant->version == SJPEG_EXYNOS7) {
>>>>> + exynos4_jpeg_set_interrupt(jpeg->regs,
>>>> SJPEG_EXYNOS7);
>>>>> + exynos4_jpeg_set_enc_out_fmt(jpeg->regs,
>>>>> + ctx->subsampling,
>>>> EXYNOS7_ENC_FMT_MASK);
>>>>> + exynos4_jpeg_set_img_fmt(jpeg->regs,
>>>>> + ctx->out_q.fmt->fourcc,
>>>>> + EXYNOS7_SWAP_CHROMA_SHIFT);
>>>>> + } else {
>>>>> + exynos4_jpeg_set_interrupt(jpeg->regs,
>>>> SJPEG_EXYNOS4);
>>>>> + exynos4_jpeg_set_enc_out_fmt(jpeg->regs,
>>>>> + ctx->subsampling,
>>>> EXYNOS4_ENC_FMT_MASK);
>>>>> + exynos4_jpeg_set_img_fmt(jpeg->regs,
>>>>> + ctx->out_q.fmt->fourcc,
>>>>> + EXYNOS4_SWAP_CHROMA_SHIFT);
>>>>> + }
>>>>> +
>>>>
>>>> I'd implement it this way:
>>>>
>>>> exynos4_jpeg_set_interrupt(jpeg->regs, ctx->jpeg->variant->version);
>>>> exynos4_jpeg_set_enc_out_fmt(jpeg->regs, ctx->subsampling,
>>>> (ctx->jpeg->variant->version == SJPEG_EXYNOS4) ?
>>>> EXYNOS4_ENC_FMT_MASK :
>>>> EXYNOS7_ENC_FMT_MASK);
>>>> exynos4_jpeg_set_img_fmt(jpeg->regs, ctx->out_q.fmt->fourcc,
>>>> (ctx->jpeg->variant->version == SJPEG_EXYNOS4) ?
>>>> EXYNOS4_SWAP_CHROMA_SHIFT :
>>>> EXYNOS7_SWAP_CHROMA_SHIFT);
>>>>
>>>
>>> OK. Looks goods to me. Thanks for the suggestion.
>>>
>>>>> exynos4_jpeg_set_img_addr(ctx);
>>>>> exynos4_jpeg_set_jpeg_addr(ctx);
>>>>> exynos4_jpeg_set_encode_hoff_cnt(jpeg->regs,
>>>>>
> ctx->out_q.fmt->fourcc);
>>>>> } else {
>>>>> exynos4_jpeg_sw_reset(jpeg->regs);
>>>>> - exynos4_jpeg_set_interrupt(jpeg->regs);
>>>>> exynos4_jpeg_set_img_addr(ctx);
>>>>> exynos4_jpeg_set_jpeg_addr(ctx);
>>>>> - exynos4_jpeg_set_img_fmt(jpeg->regs, ctx->cap_q.fmt-
>>>>> fourcc);
>>>>>
>>>>> - bitstream_size = DIV_ROUND_UP(ctx->out_q.size, 32);
>>>>> + if (ctx->jpeg->variant->version == SJPEG_EXYNOS7) {
>>>>> + exynos4_jpeg_set_interrupt(jpeg->regs,
>>>> SJPEG_EXYNOS7);
>>>>> + exynos4_jpeg_set_huff_tbl(jpeg->regs);
>>>>> + exynos4_jpeg_set_huf_table_enable(jpeg->regs, 1);
>>>>> +
>>>>> + /*
>>>>> + * JPEG IP allows storing 4 quantization tables
>>>>> + * We fill table 0 for luma and table 1 for chroma
>>>>> + */
>>>>> + exynos4_jpeg_set_qtbl_lum(jpeg->regs,
>>>>> + ctx->compr_quality);
>>>>> + exynos4_jpeg_set_qtbl_chr(jpeg->regs,
>>>>> + ctx->compr_quality);
>>>>
>>>> Is it really required to setup quantization tables for encoding?
>>>>
>>>
>>> Without setting up the quantization tables, encoder is working fine.
>>> But, as per Exynos7 User Manual setting up the quantization tables are
>>> required for encoding also.
>>
>
> Sorry I also got it mixed up.
> *Decoder* works fine without setting up the quantization tables. But this step
> is mentioned in User Manual.
I'm ok with it provided that you will get an ack from Samsung SOCs
maintainer.
>> Actually I intended to ask if setting the quantization tables is required for
>> *decoding*, as you set it also in decoding path, whereas for Exynos4 it is not
>> required. I looks strange for me as quantization tables are usually required
> only
>> for encoding raw images.
>> The same is related to huffman tables.
>
> Huffman table is required for Exynos7 decoding.
> User Manual says about Update_Huf_Tbl [bit 19 of PEG_CNTL], "User/Host should
> mandatory program this Bit as "1" for every decoder operation. SFR
> "HUFF_TBL_ENT" and SFR "HUFF_CNT" should be programmed accordingly for every
> encoder/decoder operation."
Same situation as above.
>>
>>>>> + exynos4_jpeg_set_stream_size(jpeg->regs, ctx-
>>>>> cap_q.w,
>>>>> + ctx->cap_q.h);
>>>>
>>>> For exynos4 this function writes the number of samples per line and
>>>> number lines of the resulting JPEG image and is used only during
>>>> encoding. Is the semantics of the related register different in case of
> Exynos7?
>>>>
>>>
>>> Yes. In case of Exynos7 Encoding, This step is required.
>>
>> Ack.
>
> I will request Kukjin or any Samsung colleagues who has access to Exynos7 Manual
> to give ack or tested by.
This is a good idea.
--
Best Regards,
Jacek Anaszewski
--
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
WARNING: multiple messages have this Message-ID (diff)
From: j.anaszewski@samsung.com (Jacek Anaszewski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support
Date: Wed, 07 Jan 2015 13:39:25 +0100 [thread overview]
Message-ID: <54AD28FD.4020703@samsung.com> (raw)
In-Reply-To: <000a01d02a72$bc6e06b0$354a1410$@samsung.com>
Hi Tony,
On 01/07/2015 01:08 PM, Tony K Nadackal wrote:
> Dear Jacek,
>
> On Wednesday, January 07, 2015 3:15 PM Jacek Anaszewski wrote,
>
>> Hi Tony,
>>
>> Sorry for late response, just got back from vacation.
>>
>> On 12/19/2014 04:37 AM, Tony K Nadackal wrote:
>>> Hi Jacek,
>>>
>>> On Wednesday, December 17, 2014 7:46 PM Jacek Anaszewski wrote,
>>>> Hi Tony,
>>>>
>>>> Thanks for the patches.
>>>>
>>>
>>> Thanks for the review.
>>>
>>>> Please process them with scripts/checkpatch.pl as you will be
>>>> submitting the
>>> next
>>>> version - they contain many coding style related issues.
>>>>
>>>
>>> I ran checkpatch before posting. Do you find any checkpatch related
>>> issues in the patch?
>>
>> There was a problem on my side, sorry for making confusion.
>>
>>>> My remaining comments below.
>>>>
>>>
>>> [snip]
>>>
>>>>> + if (ctx->jpeg->variant->version == SJPEG_EXYNOS7) {
>>>>> + exynos4_jpeg_set_interrupt(jpeg->regs,
>>>> SJPEG_EXYNOS7);
>>>>> + exynos4_jpeg_set_enc_out_fmt(jpeg->regs,
>>>>> + ctx->subsampling,
>>>> EXYNOS7_ENC_FMT_MASK);
>>>>> + exynos4_jpeg_set_img_fmt(jpeg->regs,
>>>>> + ctx->out_q.fmt->fourcc,
>>>>> + EXYNOS7_SWAP_CHROMA_SHIFT);
>>>>> + } else {
>>>>> + exynos4_jpeg_set_interrupt(jpeg->regs,
>>>> SJPEG_EXYNOS4);
>>>>> + exynos4_jpeg_set_enc_out_fmt(jpeg->regs,
>>>>> + ctx->subsampling,
>>>> EXYNOS4_ENC_FMT_MASK);
>>>>> + exynos4_jpeg_set_img_fmt(jpeg->regs,
>>>>> + ctx->out_q.fmt->fourcc,
>>>>> + EXYNOS4_SWAP_CHROMA_SHIFT);
>>>>> + }
>>>>> +
>>>>
>>>> I'd implement it this way:
>>>>
>>>> exynos4_jpeg_set_interrupt(jpeg->regs, ctx->jpeg->variant->version);
>>>> exynos4_jpeg_set_enc_out_fmt(jpeg->regs, ctx->subsampling,
>>>> (ctx->jpeg->variant->version == SJPEG_EXYNOS4) ?
>>>> EXYNOS4_ENC_FMT_MASK :
>>>> EXYNOS7_ENC_FMT_MASK);
>>>> exynos4_jpeg_set_img_fmt(jpeg->regs, ctx->out_q.fmt->fourcc,
>>>> (ctx->jpeg->variant->version == SJPEG_EXYNOS4) ?
>>>> EXYNOS4_SWAP_CHROMA_SHIFT :
>>>> EXYNOS7_SWAP_CHROMA_SHIFT);
>>>>
>>>
>>> OK. Looks goods to me. Thanks for the suggestion.
>>>
>>>>> exynos4_jpeg_set_img_addr(ctx);
>>>>> exynos4_jpeg_set_jpeg_addr(ctx);
>>>>> exynos4_jpeg_set_encode_hoff_cnt(jpeg->regs,
>>>>>
> ctx->out_q.fmt->fourcc);
>>>>> } else {
>>>>> exynos4_jpeg_sw_reset(jpeg->regs);
>>>>> - exynos4_jpeg_set_interrupt(jpeg->regs);
>>>>> exynos4_jpeg_set_img_addr(ctx);
>>>>> exynos4_jpeg_set_jpeg_addr(ctx);
>>>>> - exynos4_jpeg_set_img_fmt(jpeg->regs, ctx->cap_q.fmt-
>>>>> fourcc);
>>>>>
>>>>> - bitstream_size = DIV_ROUND_UP(ctx->out_q.size, 32);
>>>>> + if (ctx->jpeg->variant->version == SJPEG_EXYNOS7) {
>>>>> + exynos4_jpeg_set_interrupt(jpeg->regs,
>>>> SJPEG_EXYNOS7);
>>>>> + exynos4_jpeg_set_huff_tbl(jpeg->regs);
>>>>> + exynos4_jpeg_set_huf_table_enable(jpeg->regs, 1);
>>>>> +
>>>>> + /*
>>>>> + * JPEG IP allows storing 4 quantization tables
>>>>> + * We fill table 0 for luma and table 1 for chroma
>>>>> + */
>>>>> + exynos4_jpeg_set_qtbl_lum(jpeg->regs,
>>>>> + ctx->compr_quality);
>>>>> + exynos4_jpeg_set_qtbl_chr(jpeg->regs,
>>>>> + ctx->compr_quality);
>>>>
>>>> Is it really required to setup quantization tables for encoding?
>>>>
>>>
>>> Without setting up the quantization tables, encoder is working fine.
>>> But, as per Exynos7 User Manual setting up the quantization tables are
>>> required for encoding also.
>>
>
> Sorry I also got it mixed up.
> *Decoder* works fine without setting up the quantization tables. But this step
> is mentioned in User Manual.
I'm ok with it provided that you will get an ack from Samsung SOCs
maintainer.
>> Actually I intended to ask if setting the quantization tables is required for
>> *decoding*, as you set it also in decoding path, whereas for Exynos4 it is not
>> required. I looks strange for me as quantization tables are usually required
> only
>> for encoding raw images.
>> The same is related to huffman tables.
>
> Huffman table is required for Exynos7 decoding.
> User Manual says about Update_Huf_Tbl [bit 19 of PEG_CNTL], "User/Host should
> mandatory program this Bit as "1" for every decoder operation. SFR
> "HUFF_TBL_ENT" and SFR "HUFF_CNT" should be programmed accordingly for every
> encoder/decoder operation."
Same situation as above.
>>
>>>>> + exynos4_jpeg_set_stream_size(jpeg->regs, ctx-
>>>>> cap_q.w,
>>>>> + ctx->cap_q.h);
>>>>
>>>> For exynos4 this function writes the number of samples per line and
>>>> number lines of the resulting JPEG image and is used only during
>>>> encoding. Is the semantics of the related register different in case of
> Exynos7?
>>>>
>>>
>>> Yes. In case of Exynos7 Encoding, This step is required.
>>
>> Ack.
>
> I will request Kukjin or any Samsung colleagues who has access to Exynos7 Manual
> to give ack or tested by.
This is a good idea.
--
Best Regards,
Jacek Anaszewski
WARNING: multiple messages have this Message-ID (diff)
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Tony K Nadackal <tony.kn@samsung.com>
Cc: linux-media@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, devicetree@vger.kernel.org,
mchehab@osg.samsung.com, kgene@kernel.org, k.debski@samsung.com,
s.nawrocki@samsung.com, robh+dt@kernel.org, mark.rutland@arm.com,
bhushan.r@samsung.com
Subject: Re: [PATCH] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support
Date: Wed, 07 Jan 2015 13:39:25 +0100 [thread overview]
Message-ID: <54AD28FD.4020703@samsung.com> (raw)
In-Reply-To: <000a01d02a72$bc6e06b0$354a1410$@samsung.com>
Hi Tony,
On 01/07/2015 01:08 PM, Tony K Nadackal wrote:
> Dear Jacek,
>
> On Wednesday, January 07, 2015 3:15 PM Jacek Anaszewski wrote,
>
>> Hi Tony,
>>
>> Sorry for late response, just got back from vacation.
>>
>> On 12/19/2014 04:37 AM, Tony K Nadackal wrote:
>>> Hi Jacek,
>>>
>>> On Wednesday, December 17, 2014 7:46 PM Jacek Anaszewski wrote,
>>>> Hi Tony,
>>>>
>>>> Thanks for the patches.
>>>>
>>>
>>> Thanks for the review.
>>>
>>>> Please process them with scripts/checkpatch.pl as you will be
>>>> submitting the
>>> next
>>>> version - they contain many coding style related issues.
>>>>
>>>
>>> I ran checkpatch before posting. Do you find any checkpatch related
>>> issues in the patch?
>>
>> There was a problem on my side, sorry for making confusion.
>>
>>>> My remaining comments below.
>>>>
>>>
>>> [snip]
>>>
>>>>> + if (ctx->jpeg->variant->version == SJPEG_EXYNOS7) {
>>>>> + exynos4_jpeg_set_interrupt(jpeg->regs,
>>>> SJPEG_EXYNOS7);
>>>>> + exynos4_jpeg_set_enc_out_fmt(jpeg->regs,
>>>>> + ctx->subsampling,
>>>> EXYNOS7_ENC_FMT_MASK);
>>>>> + exynos4_jpeg_set_img_fmt(jpeg->regs,
>>>>> + ctx->out_q.fmt->fourcc,
>>>>> + EXYNOS7_SWAP_CHROMA_SHIFT);
>>>>> + } else {
>>>>> + exynos4_jpeg_set_interrupt(jpeg->regs,
>>>> SJPEG_EXYNOS4);
>>>>> + exynos4_jpeg_set_enc_out_fmt(jpeg->regs,
>>>>> + ctx->subsampling,
>>>> EXYNOS4_ENC_FMT_MASK);
>>>>> + exynos4_jpeg_set_img_fmt(jpeg->regs,
>>>>> + ctx->out_q.fmt->fourcc,
>>>>> + EXYNOS4_SWAP_CHROMA_SHIFT);
>>>>> + }
>>>>> +
>>>>
>>>> I'd implement it this way:
>>>>
>>>> exynos4_jpeg_set_interrupt(jpeg->regs, ctx->jpeg->variant->version);
>>>> exynos4_jpeg_set_enc_out_fmt(jpeg->regs, ctx->subsampling,
>>>> (ctx->jpeg->variant->version == SJPEG_EXYNOS4) ?
>>>> EXYNOS4_ENC_FMT_MASK :
>>>> EXYNOS7_ENC_FMT_MASK);
>>>> exynos4_jpeg_set_img_fmt(jpeg->regs, ctx->out_q.fmt->fourcc,
>>>> (ctx->jpeg->variant->version == SJPEG_EXYNOS4) ?
>>>> EXYNOS4_SWAP_CHROMA_SHIFT :
>>>> EXYNOS7_SWAP_CHROMA_SHIFT);
>>>>
>>>
>>> OK. Looks goods to me. Thanks for the suggestion.
>>>
>>>>> exynos4_jpeg_set_img_addr(ctx);
>>>>> exynos4_jpeg_set_jpeg_addr(ctx);
>>>>> exynos4_jpeg_set_encode_hoff_cnt(jpeg->regs,
>>>>>
> ctx->out_q.fmt->fourcc);
>>>>> } else {
>>>>> exynos4_jpeg_sw_reset(jpeg->regs);
>>>>> - exynos4_jpeg_set_interrupt(jpeg->regs);
>>>>> exynos4_jpeg_set_img_addr(ctx);
>>>>> exynos4_jpeg_set_jpeg_addr(ctx);
>>>>> - exynos4_jpeg_set_img_fmt(jpeg->regs, ctx->cap_q.fmt-
>>>>> fourcc);
>>>>>
>>>>> - bitstream_size = DIV_ROUND_UP(ctx->out_q.size, 32);
>>>>> + if (ctx->jpeg->variant->version == SJPEG_EXYNOS7) {
>>>>> + exynos4_jpeg_set_interrupt(jpeg->regs,
>>>> SJPEG_EXYNOS7);
>>>>> + exynos4_jpeg_set_huff_tbl(jpeg->regs);
>>>>> + exynos4_jpeg_set_huf_table_enable(jpeg->regs, 1);
>>>>> +
>>>>> + /*
>>>>> + * JPEG IP allows storing 4 quantization tables
>>>>> + * We fill table 0 for luma and table 1 for chroma
>>>>> + */
>>>>> + exynos4_jpeg_set_qtbl_lum(jpeg->regs,
>>>>> + ctx->compr_quality);
>>>>> + exynos4_jpeg_set_qtbl_chr(jpeg->regs,
>>>>> + ctx->compr_quality);
>>>>
>>>> Is it really required to setup quantization tables for encoding?
>>>>
>>>
>>> Without setting up the quantization tables, encoder is working fine.
>>> But, as per Exynos7 User Manual setting up the quantization tables are
>>> required for encoding also.
>>
>
> Sorry I also got it mixed up.
> *Decoder* works fine without setting up the quantization tables. But this step
> is mentioned in User Manual.
I'm ok with it provided that you will get an ack from Samsung SOCs
maintainer.
>> Actually I intended to ask if setting the quantization tables is required for
>> *decoding*, as you set it also in decoding path, whereas for Exynos4 it is not
>> required. I looks strange for me as quantization tables are usually required
> only
>> for encoding raw images.
>> The same is related to huffman tables.
>
> Huffman table is required for Exynos7 decoding.
> User Manual says about Update_Huf_Tbl [bit 19 of PEG_CNTL], "User/Host should
> mandatory program this Bit as "1" for every decoder operation. SFR
> "HUFF_TBL_ENT" and SFR "HUFF_CNT" should be programmed accordingly for every
> encoder/decoder operation."
Same situation as above.
>>
>>>>> + exynos4_jpeg_set_stream_size(jpeg->regs, ctx-
>>>>> cap_q.w,
>>>>> + ctx->cap_q.h);
>>>>
>>>> For exynos4 this function writes the number of samples per line and
>>>> number lines of the resulting JPEG image and is used only during
>>>> encoding. Is the semantics of the related register different in case of
> Exynos7?
>>>>
>>>
>>> Yes. In case of Exynos7 Encoding, This step is required.
>>
>> Ack.
>
> I will request Kukjin or any Samsung colleagues who has access to Exynos7 Manual
> to give ack or tested by.
This is a good idea.
--
Best Regards,
Jacek Anaszewski
next prev parent reply other threads:[~2015-01-07 12:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 7:27 [PATCH] [media] s5p-jpeg: Adding Exynos7 Jpeg variant support Tony K Nadackal
2014-12-17 7:27 ` Tony K Nadackal
2014-12-17 14:15 ` Jacek Anaszewski
2014-12-17 14:15 ` Jacek Anaszewski
2014-12-19 3:37 ` Tony K Nadackal
2014-12-19 3:37 ` Tony K Nadackal
2015-01-07 9:45 ` Jacek Anaszewski
2015-01-07 9:45 ` Jacek Anaszewski
2015-01-07 9:45 ` Jacek Anaszewski
2015-01-07 12:08 ` Tony K Nadackal
2015-01-07 12:08 ` Tony K Nadackal
2015-01-07 12:39 ` Jacek Anaszewski [this message]
2015-01-07 12:39 ` Jacek Anaszewski
2015-01-07 12:39 ` Jacek Anaszewski
2015-01-12 11:27 ` Tony K Nadackal
2015-01-12 11:27 ` Tony K Nadackal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54AD28FD.4020703@samsung.com \
--to=j.anaszewski-sze3o3uu22jbdgjk7y7tuq@public.gmane.org \
--cc=bhushan.r-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=k.debski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=tony.kn-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.