@@ -75,6 +75,31 @@ struct mtk_jpeg_variant {u32cap_q_default_fourcc;};+enummtk_jpegenc_hw_id{+MTK_JPEGENC_HW0,+MTK_JPEGENC_HW1,+MTK_JPEGENC_HW_MAX,+};++/** * struct mtk_jpegenc_clk_info - Structure used to store clock name */+structmtk_jpegenc_clk_info{+constchar*clk_name;+structclk*jpegenc_clk;+};++/* struct mtk_vcodec_clk - Structure used to store vcodec clock information */+structmtk_jpegenc_clk{+structmtk_jpegenc_clk_info*clk_info;+intclk_num;+};++/** * struct mtk_vcodec_pm - Power management data structure */+structmtk_jpegenc_pm{+structmtk_jpegenc_clkvenc_clk;+structdevice*dev;+structmtk_jpeg_dev*mtkdev;+};+/***structmtk_jpeg_dev-JPEGIPabstraction*@lock:themutexprotectingthisstructure
the func of jpgenc irq handler would not compatible, remove those
code.
Signed-off-by: kyrie.wu <redacted>
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 48 -------------------------
1 file changed, 48 deletions(-)
@@ -1493,12 +1494,99 @@ static inline void mtk_jpeg_clk_release(struct mtk_jpeg_dev *jpeg)put_device(jpeg->larb);}+staticconststructof_device_idmtk_jpegenc_drv_ids[]={+{+.compatible="mediatek,mt8195-jpgenc0",+.data=(void*)MTK_JPEGENC_HW0,+},+{+.compatible="mediatek,mt8195-jpgenc1",+.data=(void*)MTK_JPEGENC_HW1,+},+{},+};++staticinlineintmtk_vdec_compare_of(structdevice*dev,void*data)+{+returndev->of_node==data;+}++staticinlinevoidmtk_vdec_release_of(structdevice*dev,void*data)+{+of_node_put(data);+}++staticinlineintmtk_jpegenc_bind(structdevice*dev)+{+structmtk_jpeg_dev*data=dev_get_drvdata(dev);++returncomponent_bind_all(dev,data);+}++staticinlinevoidmtk_jpegenc_unbind(structdevice*dev)+{+structmtk_jpeg_dev*data=dev_get_drvdata(dev);++component_unbind_all(dev,data);+}++staticconststructcomponent_master_opsmtk_jpegenc_ops={+.bind=mtk_jpegenc_bind,+.unbind=mtk_jpegenc_unbind,+};++staticstructcomponent_match*mtk_jpegenc_match_add(structmtk_jpeg_dev*jpeg)+{+structdevice*dev=jpeg->dev;+structcomponent_match*match=NULL;+inti;+charcompatible[128]={0};++for(i=0;i<ARRAY_SIZE(mtk_jpegenc_drv_ids);i++){+structdevice_node*comp_node;+enummtk_jpegenc_hw_idcomp_idx;+conststructof_device_id*of_id;++memcpy(compatible,mtk_jpegenc_drv_ids[i].compatible,+sizeof(mtk_jpegenc_drv_ids[i].compatible));++comp_node=of_find_compatible_node(NULL,NULL,+compatible);+if(!comp_node)+continue;++if(!of_device_is_available(comp_node)){+of_node_put(comp_node);+v4l2_err(&jpeg->v4l2_dev,"Fail to get jpeg enc HW node\n");+continue;+}++of_id=of_match_node(mtk_jpegenc_drv_ids,comp_node);+if(!of_id){+v4l2_err(&jpeg->v4l2_dev,"Failed to get match node\n");+returnERR_PTR(-EINVAL);+}++comp_idx=(enummtk_jpegenc_hw_id)of_id->data;+v4l2_info(&jpeg->v4l2_dev,"Get component:hw_id(%d),jpeg_dev(0x%p),comp_node(0x%p)\n",+comp_idx,jpeg,comp_node);++jpeg->component_node[comp_idx]=comp_node;++component_match_add_release(dev,&match,mtk_vdec_release_of,+mtk_vdec_compare_of,comp_node);+}++returnmatch;+}+staticintmtk_jpeg_probe(structplatform_device*pdev){structmtk_jpeg_dev*jpeg;structresource*res;intjpeg_irq;intret;+structcomponent_match*match;jpeg=devm_kzalloc(&pdev->dev,sizeof(*jpeg),GFP_KERNEL);if(!jpeg)
@@ -1510,31 +1598,47 @@ static int mtk_jpeg_probe(struct platform_device *pdev)jpeg->variant=of_device_get_match_data(jpeg->dev);INIT_DELAYED_WORK(&jpeg->job_timeout_work,mtk_jpeg_job_timeout_work);-res=platform_get_resource(pdev,IORESOURCE_MEM,0);-jpeg->reg_base[0]=devm_ioremap_resource(&pdev->dev,res);-if(IS_ERR(jpeg->reg_base)){-ret=PTR_ERR(jpeg->reg_base);-returnret;-}+if(!jpeg->variant->is_encoder){+res=platform_get_resource(pdev,IORESOURCE_MEM,0);+jpeg->reg_base[MTK_JPEGENC_HW0]=+devm_ioremap_resource(&pdev->dev,res);+if(IS_ERR(jpeg->reg_base[MTK_JPEGENC_HW0])){+ret=PTR_ERR(jpeg->reg_base[MTK_JPEGENC_HW0]);+returnret;+}-jpeg_irq=platform_get_irq(pdev,0);-if(jpeg_irq<0){-dev_err(&pdev->dev,"Failed to get jpeg_irq %d.\n",jpeg_irq);-returnjpeg_irq;-}+jpeg_irq=platform_get_irq(pdev,0);+if(jpeg_irq<0){+dev_err(&pdev->dev,"Failed to get jpeg_irq %d.\n",+jpeg_irq);+returnjpeg_irq;+}-ret=devm_request_irq(&pdev->dev,jpeg_irq,-jpeg->variant->irq_handler,0,pdev->name,jpeg);-if(ret){-dev_err(&pdev->dev,"Failed to request jpeg_irq %d (%d)\n",-jpeg_irq,ret);-gotoerr_req_irq;-}+ret=devm_request_irq(&pdev->dev,jpeg_irq,+jpeg->variant->irq_handler,+0,pdev->name,jpeg);+if(ret){+dev_err(&pdev->dev,"Failed to request jpeg_irq %d (%d)\n",+jpeg_irq,ret);+gotoerr_req_irq;+}-ret=mtk_jpeg_clk_init(jpeg);-if(ret){-dev_err(&pdev->dev,"Failed to init clk, err %d\n",ret);-gotoerr_clk_init;+ret=mtk_jpeg_clk_init(jpeg);+if(ret){+dev_err(&pdev->dev,"Failed to init clk\n");+gotoerr_clk_init;+}+}else{+init_waitqueue_head(&jpeg->hw_wq);++jpeg->workqueue=alloc_ordered_workqueue(MTK_JPEG_NAME,+WQ_MEM_RECLAIM|+WQ_FREEZABLE);+if(!jpeg->workqueue){+dev_err(&pdev->dev,"Failed to create jpeg workqueue!\n");+ret=-EINVAL;+gotoerr_alloc_workqueue;+}}ret=v4l2_device_register(&pdev->dev,&jpeg->v4l2_dev);
@@ -1583,7 +1687,20 @@ static int mtk_jpeg_probe(struct platform_device *pdev)platform_set_drvdata(pdev,jpeg);-pm_runtime_enable(&pdev->dev);+if(jpeg->variant->is_encoder){+match=mtk_jpegenc_match_add(jpeg);+if(IS_ERR_OR_NULL(match))+gotoerr_vfd_jpeg_register;++video_set_drvdata(jpeg->vdev,jpeg);+platform_set_drvdata(pdev,jpeg);+ret=component_master_add_with_match(&pdev->dev,+&mtk_jpegenc_ops,match);+if(ret<0)+gotoerr_vfd_jpeg_register;+}else{+pm_runtime_enable(&pdev->dev);+}return0;
@@ -1601,6 +1718,8 @@ static int mtk_jpeg_probe(struct platform_device *pdev)err_clk_init:+err_alloc_workqueue:+err_req_irq:returnret;
@@ -153,6 +163,182 @@ void mtk_jpeg_set_enc_params(struct mtk_jpeg_ctx *ctx, void __iomem *base)writel(ctx->restart_interval,base+JPEG_ENC_RST_MCU_NUM);}+staticintmtk_jpegenc_hw_bind(structdevice*dev,+structdevice*master,void*data)+{+structmtk_jpeg_dev*comp_priv=dev_get_drvdata(dev);+structmtk_jpeg_dev*master_priv=data;+inti;++for(i=0;i<MTK_JPEGENC_HW_MAX;i++){+if(dev->of_node!=master_priv->component_node[i])+continue;+master_priv->hw_dev[i]=comp_priv;+comp_priv->comp_idx=i;+master_priv->reg_base[i]=comp_priv->reg_base[MTK_JPEGENC_HW0];+break;+}+if(i==MTK_JPEGENC_HW_MAX){+dev_err(dev,"Failed to get component node\n");+return-EINVAL;+}+return0;+}++staticvoidmtk_jpegenc_hw_unbind(structdevice*dev,+structdevice*master,void*data)+{+structmtk_jpeg_dev*comp_priv=dev_get_drvdata(dev);++comp_priv->reg_base[MTK_JPEGENC_HW0]=0;+}++staticconststructcomponent_opsmtk_jpegenc_hw_component_ops={+.bind=mtk_jpegenc_hw_bind,+.unbind=mtk_jpegenc_hw_unbind,+};++intmtk_jpegenc_init_pm(structmtk_jpeg_dev*mtkdev)+{+structplatform_device*pdev;+structmtk_jpegenc_pm*pm;+structmtk_jpegenc_clk*jpegenc_clk;+structmtk_jpegenc_clk_info*clk_info;+inti,ret;++pdev=mtkdev->plat_dev;+pm->dev=&pdev->dev;+pm=&mtkdev->pm;+pm->mtkdev=mtkdev;+jpegenc_clk=&pm->venc_clk;+jpegenc_clk->clk_num=+of_property_count_strings(pdev->dev.of_node,"clock-names");+if(!jpegenc_clk->clk_num){+dev_err(&pdev->dev,"Failed to get jpegenc clock count\n");+return-EINVAL;+}++jpegenc_clk->clk_info=devm_kcalloc(&pdev->dev,+jpegenc_clk->clk_num,+sizeof(*clk_info),+GFP_KERNEL);+if(!jpegenc_clk->clk_info)+return-ENOMEM;++for(i=0;i<jpegenc_clk->clk_num;i++){+clk_info=&jpegenc_clk->clk_info[i];+ret=of_property_read_string_index(pdev->dev.of_node,+"clock-names",i,+&clk_info->clk_name);+if(ret){+dev_err(&pdev->dev,"Failed to get jpegenc clock name\n");+returnret;+}++clk_info->jpegenc_clk=devm_clk_get(&pdev->dev,+clk_info->clk_name);+if(IS_ERR(clk_info->jpegenc_clk)){+dev_err(&pdev->dev,"devm_clk_get (%d)%s fail",+i,clk_info->clk_name);+returnPTR_ERR(clk_info->jpegenc_clk);+}+}++pm_runtime_enable(&pdev->dev);++returnret;+}++voidmtk_jpegenc_release_pm(structmtk_jpeg_dev*mtkdev)+{+structplatform_device*pdev=mtkdev->plat_dev;++pm_runtime_disable(&pdev->dev);+}++staticintmtk_jpegenc_hw_init_irq(structmtk_jpeg_dev*dev)+{+structplatform_device*pdev=dev->plat_dev;+intret;++dev->jpegenc_irq=platform_get_irq(pdev,0);+if(dev->jpegenc_irq<0){+dev_err(&pdev->dev,"Failed to get irq resource");+returndev->jpegenc_irq;+}++ret=devm_request_irq(&pdev->dev,dev->jpegenc_irq,+mtk_jpegenc_hw_irq_handler,0,pdev->name,dev);+if(ret){+dev_err(&pdev->dev,"Failed to devm_request_irq %d (%d)",+dev->jpegenc_irq,ret);++return-ENOENT;+}++return0;+}++staticintmtk_jpegenc_hw_probe(structplatform_device*pdev)+{+structmtk_jpeg_dev*dev;+intret;++dev=devm_kzalloc(&pdev->dev,sizeof(*dev),GFP_KERNEL);+if(!dev)+return-ENOMEM;+dev->plat_dev=pdev;+spin_lock_init(&dev->irqlock);+mutex_init(&dev->dev_mutex);+atomic_set(&dev->hw_rdy,1U);+spin_lock_init(&dev->hw_lock);++dev->hw_state=MTK_JPEG_HW_IDLE;+INIT_DELAYED_WORK(&dev->job_timeout_work,mtk_jpegenc_timeout_work);++ret=mtk_jpegenc_init_pm(dev);+if(ret){+dev_err(&pdev->dev,"Failed to get jpeg enc clock source");+returnret;+}++dev->reg_base[MTK_JPEGENC_HW0]=+devm_platform_ioremap_resource(pdev,0);+if(IS_ERR((__forcevoid*)dev->reg_base[MTK_JPEGENC_HW0])){+ret=PTR_ERR((__forcevoid*)dev->reg_base[MTK_JPEGENC_HW0]);+gotoerr;+}++ret=mtk_jpegenc_hw_init_irq(dev);+if(ret){+dev_err(&pdev->dev,"Failed to register JPEGENC irq handler.\n");+gotoerr;+}++platform_set_drvdata(pdev,dev);++ret=component_add(&pdev->dev,&mtk_jpegenc_hw_component_ops);+if(ret){+dev_err(&pdev->dev,"Failed to component_add: %d\n",ret);+gotoerr;+}++return0;++err:+mtk_jpegenc_release_pm(dev);+returnret;+}++staticintmtk_jpegenc_remove(structplatform_device*pdev)+{+structmtk_jpeg_dev*dev=platform_get_drvdata(pdev);++mtk_jpegenc_release_pm(dev);++return0;+}+#if defined(CONFIG_OF)staticconststructof_device_idmtk_jpegenc_hw_ids[]={{
The series has some consistency issues which would make readers feel
uncomfortable.
For example:
- Whether to capitalize the first characters in the commit messages/titles.
- Whether to add a period at the end of English sentences.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jun 30, 2021 at 3:32 PM kyrie.wu [off-list ref] wrote:
Add MT8195 JPEG venc driver's compatible and device private data.
compatible = "mediatek,mt8195-jpgenc": this node would only register
jpgenc device node;
compatible = "mediatek,mt8195-jpgenc0": HW0 node, this node would not
register jpgenc device node, but register irq, init clk and power,
remmap register base and do other resource options;
compatible = "mediatek,mt8195-jpgenc1": HW1 node, just like HW0 node;
The commit message is not easy to read. Please rephrase the sentences.
What does "venc" stand for? I believe it is a copy-n-paste typo.
The commit title "support MT8195 JPEG encoder" looks better to me.
Would expect somewhere to reference mtk_jpegenc_hw_ids but failed to find it.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jun 30, 2021 at 3:28 PM kyrie.wu [off-list ref] wrote:
the func of jpgenc irq handler would not compatible, remove those
code.
Need more explanation about why as I believe it is non-backward compatible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Consistency issue: mtk_jpeg_clk_on() has struct mtk_jpegenc_clk_info
*clk_info. Why not also have the local variable here?
Is it a good idea to just separate functions for ->is_encoder for
mtk_jpeg_clk_on() and mtk_jpeg_clk_off()? For example,
mtk_jpegenc_clk_on() and mtk_jpegdec_clk_on().
quoted hunk
+/** * struct mtk_jpegenc_clk_info - Structure used to store clock name */
+struct mtk_jpegenc_clk_info {
+ const char *clk_name;
+ struct clk *jpegenc_clk;
+};
+
+/* struct mtk_vcodec_clk - Structure used to store vcodec clock information */
+struct mtk_jpegenc_clk {
+ struct mtk_jpegenc_clk_info *clk_info;
+ int clk_num;
+};
+
+/** * struct mtk_vcodec_pm - Power management data structure */
+struct mtk_jpegenc_pm {
+ struct mtk_jpegenc_clk venc_clk;
+ struct device *dev;
+ struct mtk_jpeg_dev *mtkdev;
+};
+
/**
* struct mtk_jpeg_dev - JPEG IP abstraction
* @lock: the mutex protecting this structure
total_frame_num is not used.
Need to double confirm: why sometimes the code uses
jpeg->reg_base[MTK_JPEGENC_HW0] but sometimes jpeg->reg_base[0]?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Could they be inlined to above where the variables are declared?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
+
+ for (i = 0; i < ARRAY_SIZE(mtk_jpegenc_drv_ids); i++) {
+ struct device_node *comp_node;
+ enum mtk_jpegenc_hw_id comp_idx;
+ const struct of_device_id *of_id;
+
+ memcpy(compatible, mtk_jpegenc_drv_ids[i].compatible,
+ sizeof(mtk_jpegenc_drv_ids[i].compatible));
Shouldn't rely on the source length. Also needs to use strcpy-family
for better handling the NULL terminator.
+ if (!of_device_is_available(comp_node)) {
+ of_node_put(comp_node);
+ v4l2_err(&jpeg->v4l2_dev, "Fail to get jpeg enc HW node\n");
To be consistent, use "Failed".
+ of_id = of_match_node(mtk_jpegenc_drv_ids, comp_node);
+ if (!of_id) {
+ v4l2_err(&jpeg->v4l2_dev, "Failed to get match node\n");
+ return ERR_PTR(-EINVAL);
Could they be inlined to above where the variables are declared.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
The series has some consistency issues which would make readers feel
uncomfortable.
For example:
- Whether to capitalize the first characters in the commit messages/titles.
- Whether to add a period at the end of English sentences.
FWIW, it's not customary to add a period at the end of a patch subject.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Tomasz Figa <tfiga@chromium.org> Date: 2021-07-09 09:07:23
On Tue, Jul 06, 2021 at 07:00:33PM +0800, Tzung-Bi Shih wrote:
On Wed, Jun 30, 2021 at 3:28 PM kyrie.wu [off-list ref] wrote:
quoted
the func of jpgenc irq handler would not compatible, remove those
code.
Need more explanation about why as I believe it is non-backward compatible.
Right. And it breaks bisection, which is not acceptable.
Kyrie, please structure your series in a way that none of the patches
break any existing functionality.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Tomasz Figa <tfiga@chromium.org> Date: 2021-07-09 09:20:26
Hi Kyrie,
On Wed, Jun 30, 2021 at 03:27:54PM +0800, kyrie.wu wrote:
Using the needed param for lock on/off function.
Signed-off-by: kyrie.wu <redacted>
---
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 46 ++++++++++++++++++++++++-
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 28 +++++++++++++++
2 files changed, 73 insertions(+), 1 deletion(-)
Thanks for the patch. Please see my comments inline.
Also, how does this patch refactor anything? I only see new code being
added. Does the subject and/or commit message need some adjustment?
Why do we need to enable clocks for all hardware instances? Wouldn't it
make more sense to only enable the clock for the instance that is
selected for given encode job?
+ comp_dev = jpeg->hw_dev[i];
+ if (!comp_dev) {
+ dev_err(jpeg->dev, "Failed to get hw dev\n");
+ return;
+ }
+
+ pm = &comp_dev->pm;
+ jpegclk = &pm->venc_clk;
+ clk_info = jpegclk->clk_info;
+ ret = clk_prepare_enable(clk_info->jpegenc_clk);
+ if (ret) {
+ dev_err(jpeg->dev, "jpegenc clk enable %d %s fail\n",
+ i, jpegclk->clk_info->clk_name);
Missing undo. (But the suggestion below would take care of it.)
+ return;
+ }
+ }
How about using the clk_bulk_ API instead of the open coded loop?
+ return;
+ }
Rather than multiple if/else variants in one function, it's a common
practice to have two separate functions and then a function pointer in a
hardware variant descriptor struct pointing to the right function. It
makes the code more readable.
quoted hunk
ret = mtk_smi_larb_get(jpeg->larb);
if (ret)
@@ -1067,6 +1092,25 @@ static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg) static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg) {+ struct mtk_jpeg_dev *comp_dev;+ struct mtk_jpegenc_pm *pm;+ struct mtk_jpegenc_clk *jpegclk;+ int i;++ if (jpeg->variant->is_encoder) {+ for (i = 0; i < MTK_JPEGENC_HW_MAX; i++) {+ comp_dev = jpeg->hw_dev[i];+ if (!comp_dev) {+ dev_err(jpeg->dev, "Failed to get hw dev\n");+ return;+ }++ pm = &comp_dev->pm;+ jpegclk = &pm->venc_clk;+ clk_disable_unprepare(jpegclk->clk_info->jpegenc_clk);+ }+ return;+ }
Why is this recursively having the same struct as its children?
Should we have a separate struct that describes a hardware instance
(core?)?
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Shouldn't this be the other way around? I.e. first clock and then
runtime PM? Otherwise the power domain could be powered off while the
clock is still running.
This patch is missing the initialization of jpeg_work, so I have no idea
what the work actually does. Please reorganize your patches, so that it
adds all the interdependent pieces together. (As is, the code wouldn't
even compile if you checked out your tree to have the series up to this
patch but not the next ones, but it's a requirement for patch submission
to the kernel.)
I suspect that there is no need for a workqueue in this driver, but
let's see after you reorganize the patches.
From: Tomasz Figa <tfiga@chromium.org> Date: 2021-07-09 10:26:49
Hi Kyrie,
On Wed, Jun 30, 2021 at 4:31 PM kyrie.wu [off-list ref] wrote:
add component framework to using multi-HW for MT8195 jpeg encode.
kyrie.wu (9):
dt-bindings: mediatek: Add mediatek, mt8195-jpgenc compatible
media: mtk-jpegenc: Add MT8195 JPEG venc driver
media: mtk-jpegenc: remove redundant code of irq
media: mtk-jpegenc: Refactor jpeg clock interface
media: mtk-jpegenc: Generalize jpeg encode irq interfaces
media: mtk-jpegenc: Generalize jpegenc HW timeout interfaces
media: mtk-jpegenc: Use component framework to manage each hardware
information
media: mtk-jpegenc: Generalize jpegenc HW operations interfaces
media: mtk-jpegenc: Refactor jpegenc device run interface
.../bindings/media/mediatek-jpeg-encoder.yaml | 3 +
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 600 +++++++++++++++++----
drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 69 ++-
drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c | 208 +++++++
4 files changed, 786 insertions(+), 94 deletions(-)
---
This patch dependents on "dt-bindings: mediatek: convert mtk jpeg decoder/encoder to yaml"[1]
Please also accept this patch together with [1].
[1]https://lore.kernel.org/patchwork/patch/1445298/
Thank you for the series. However, I gave reviewing it a try and
unfortunately had a very hard time following it, because of the way
the patches are organized. Please make sure to read and understand the
kernel patch submission guide[1], adjust the series appropriately and
send a new version which I'll review.
[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel