Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [RFC PATCH v2 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
From: Artur Świgoń @ 2019-09-25  6:41 UTC (permalink / raw)
  To: Chanwoo Choi, devicetree, linux-arm-kernel, linux-samsung-soc,
	linux-kernel, linux-pm, dri-devel
  Cc: b.zolnierkie, sw0312.kim, a.swigon, krzk, inki.dae, myungjoo.ham,
	leonard.crestez, georgi.djakov, m.szyprowski
In-Reply-To: <9cd6267e-cc06-107e-9bdf-33d4b66f35da@samsung.com>

On Wed, 2019-09-25 at 15:37 +0900, Chanwoo Choi wrote:
> Hi,
> 
> On 19. 9. 25. 오후 2:44, Artur Świgoń wrote:
> > Hi,
> > 
> > On Fri, 2019-09-20 at 11:15 +0900, Chanwoo Choi wrote:
> > > Hi,
> > > 
> > > As I already replied on v1, patch1/2/3 clean-up code
> > > for readability without any behavior changes. 
> > > 
> > > I think that you better to merge patch1/2/3 to one patch.
> > 
> > Yes, when writing the cover letter I think I forgot to explain why I decided not
> > to merge these patches. Basically, none of the diff algorithms available in git
> > (I've got v2.17.1) is able to produce a readable patch with these changes
> > combined together into a single patch (functions are intermixed together in the
> > output, git thinks that 'exynos_bus_probe' is a new function).
> 
> After merged three patches, as you commented, looks like that 'exynos_bus_probe'
> is new function. Your patch style(three patches) is better than one merged patch.
> Keep your original patches. Thanks.

I know that having three separate patches is suboptimal, but they are more readable
this way. I am glad you agree. I will keep them separate. Thank you for your
comments.

> > 
> > Please take a look at the diff at the bottom of this message to see how patches
> > 01..03 look when combined. If such patch looks acceptable to you, I can merge.
> > 
> > > On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> > > > From: Artur Świgoń <a.swigon@partner.samsung.com>
> > > > 
> > > > This patch adds a new static function, exynos_bus_profile_init(), extracted
> > > > from exynos_bus_probe().
> > > > 
> > > > Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
> > > > ---
> > > >  drivers/devfreq/exynos-bus.c | 92 +++++++++++++++++++++---------------
> > > >  1 file changed, 53 insertions(+), 39 deletions(-)
> > > > 
> > > > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > > > index 29f422469960..78f38b7fb596 100644
> > > > --- a/drivers/devfreq/exynos-bus.c
> > > > +++ b/drivers/devfreq/exynos-bus.c
> > > > @@ -287,12 +287,62 @@ static int exynos_bus_parse_of(struct device_node *np,
> > > >  	return ret;
> > > >  }
> > > >  
> > > > +static int exynos_bus_profile_init(struct exynos_bus *bus,
> > > > +				   struct devfreq_dev_profile *profile)
> > > > +{
> > > > +	struct device *dev = bus->dev;
> > > > +	struct devfreq_simple_ondemand_data *ondemand_data;
> > > > +	int ret;
> > > > +
> > > > +	/* Initialize the struct profile and governor data for parent device */
> > > > +	profile->polling_ms = 50;
> > > > +	profile->target = exynos_bus_target;
> > > > +	profile->get_dev_status = exynos_bus_get_dev_status;
> > > > +	profile->exit = exynos_bus_exit;
> > > > +
> > > > +	ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> > > > +	if (!ondemand_data) {
> > > > +		ret = -ENOMEM;
> > > > +		goto err;
> > > > +	}
> > > > +	ondemand_data->upthreshold = 40;
> > > > +	ondemand_data->downdifferential = 5;
> > > > +
> > > > +	/* Add devfreq device to monitor and handle the exynos bus */
> > > > +	bus->devfreq = devm_devfreq_add_device(dev, profile,
> > > > +						DEVFREQ_GOV_SIMPLE_ONDEMAND,
> > > > +						ondemand_data);
> > > > +	if (IS_ERR(bus->devfreq)) {
> > > > +		dev_err(dev, "failed to add devfreq device\n");
> > > > +		ret = PTR_ERR(bus->devfreq);
> > > > +		goto err;
> > > > +	}
> > > > +
> > > > +	/*
> > > > +	 * Enable devfreq-event to get raw data which is used to determine
> > > > +	 * current bus load.
> > > > +	 */
> > > > +	ret = exynos_bus_enable_edev(bus);
> > > > +	if (ret < 0) {
> > > > +		dev_err(dev, "failed to enable devfreq-event devices\n");
> > > > +		goto err;
> > > > +	}
> > > > +
> > > > +	ret = exynos_bus_set_event(bus);
> > > > +	if (ret < 0) {
> > > > +		dev_err(dev, "failed to set event to devfreq-event devices\n");
> > > > +		goto err;
> > > > +	}
> > > > +
> > > > +err:
> > > > +	return ret;
> > > > +}
> > > > +
> > > >  static int exynos_bus_probe(struct platform_device *pdev)
> > > >  {
> > > >  	struct device *dev = &pdev->dev;
> > > >  	struct device_node *np = dev->of_node, *node;
> > > >  	struct devfreq_dev_profile *profile;
> > > > -	struct devfreq_simple_ondemand_data *ondemand_data;
> > > >  	struct devfreq_passive_data *passive_data;
> > > >  	struct devfreq *parent_devfreq;
> > > >  	struct exynos_bus *bus;
> > > > @@ -334,45 +384,9 @@ static int exynos_bus_probe(struct platform_device *pdev)
> > > >  	if (passive)
> > > >  		goto passive;
> > > >  
> > > > -	/* Initialize the struct profile and governor data for parent device */
> > > > -	profile->polling_ms = 50;
> > > > -	profile->target = exynos_bus_target;
> > > > -	profile->get_dev_status = exynos_bus_get_dev_status;
> > > > -	profile->exit = exynos_bus_exit;
> > > > -
> > > > -	ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> > > > -	if (!ondemand_data) {
> > > > -		ret = -ENOMEM;
> > > > +	ret = exynos_bus_profile_init(bus, profile);
> > > > +	if (ret < 0)
> > > >  		goto err;
> > > > -	}
> > > > -	ondemand_data->upthreshold = 40;
> > > > -	ondemand_data->downdifferential = 5;
> > > > -
> > > > -	/* Add devfreq device to monitor and handle the exynos bus */
> > > > -	bus->devfreq = devm_devfreq_add_device(dev, profile,
> > > > -						DEVFREQ_GOV_SIMPLE_ONDEMAND,
> > > > -						ondemand_data);
> > > > -	if (IS_ERR(bus->devfreq)) {
> > > > -		dev_err(dev, "failed to add devfreq device\n");
> > > > -		ret = PTR_ERR(bus->devfreq);
> > > > -		goto err;
> > > > -	}
> > > > -
> > > > -	/*
> > > > -	 * Enable devfreq-event to get raw data which is used to determine
> > > > -	 * current bus load.
> > > > -	 */
> > > > -	ret = exynos_bus_enable_edev(bus);
> > > > -	if (ret < 0) {
> > > > -		dev_err(dev, "failed to enable devfreq-event devices\n");
> > > > -		goto err;
> > > > -	}
> > > > -
> > > > -	ret = exynos_bus_set_event(bus);
> > > > -	if (ret < 0) {
> > > > -		dev_err(dev, "failed to set event to devfreq-event devices\n");
> > > > -		goto err;
> > > > -	}
> > > >  
> > > >  	goto out;
> > > >  passive:
> > 
> > commit cacf8e4ea0e111908d11779977c81e29d6418801
> > Author: Artur Świgoń <a.swigon@partner.samsung.com>
> > Date:   Tue Aug 27 13:17:28 2019 +0200
> > 
> >     tmp: merge patches 01-03
> >     
> >     Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
> > 
> > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > index 29f422469960..60ad4319fd80 100644
> > --- a/drivers/devfreq/exynos-bus.c
> > +++ b/drivers/devfreq/exynos-bus.c
> > @@ -287,52 +287,12 @@ static int exynos_bus_parse_of(struct device_node *np,
> >  	return ret;
> >  }
> >  
> > -static int exynos_bus_probe(struct platform_device *pdev)
> > +static int exynos_bus_profile_init(struct exynos_bus *bus,
> > +				   struct devfreq_dev_profile *profile)
> >  {
> > -	struct device *dev = &pdev->dev;
> > -	struct device_node *np = dev->of_node, *node;
> > -	struct devfreq_dev_profile *profile;
> > +	struct device *dev = bus->dev;
> >  	struct devfreq_simple_ondemand_data *ondemand_data;
> > -	struct devfreq_passive_data *passive_data;
> > -	struct devfreq *parent_devfreq;
> > -	struct exynos_bus *bus;
> > -	int ret, max_state;
> > -	unsigned long min_freq, max_freq;
> > -	bool passive = false;
> > -
> > -	if (!np) {
> > -		dev_err(dev, "failed to find devicetree node\n");
> > -		return -EINVAL;
> > -	}
> > -
> > -	bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
> > -	if (!bus)
> > -		return -ENOMEM;
> > -	mutex_init(&bus->lock);
> > -	bus->dev = &pdev->dev;
> > -	platform_set_drvdata(pdev, bus);
> > -
> > -	profile = devm_kzalloc(dev, sizeof(*profile), GFP_KERNEL);
> > -	if (!profile)
> > -		return -ENOMEM;
> > -
> > -	node = of_parse_phandle(dev->of_node, "devfreq", 0);
> > -	if (node) {
> > -		of_node_put(node);
> > -		passive = true;
> > -	} else {
> > -		ret = exynos_bus_parent_parse_of(np, bus);
> > -		if (ret < 0)
> > -			return ret;
> > -	}
> > -
> > -	/* Parse the device-tree to get the resource information */
> > -	ret = exynos_bus_parse_of(np, bus);
> > -	if (ret < 0)
> > -		goto err_reg;
> > -
> > -	if (passive)
> > -		goto passive;
> > +	int ret;
> >  
> >  	/* Initialize the struct profile and governor data for parent device */
> >  	profile->polling_ms = 50;
> > @@ -374,8 +334,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
> >  		goto err;
> >  	}
> >  
> > -	goto out;
> > -passive:
> > +err:
> > +	return ret;
> > +}
> > +
> > +static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
> > +					   struct devfreq_dev_profile *profile)
> > +{
> > +	struct device *dev = bus->dev;
> > +	struct devfreq_passive_data *passive_data;
> > +	struct devfreq *parent_devfreq;
> > +	int ret = 0;
> > +
> >  	/* Initialize the struct profile and governor data for passive device */
> >  	profile->target = exynos_bus_target;
> >  	profile->exit = exynos_bus_passive_exit;
> > @@ -404,7 +374,59 @@ static int exynos_bus_probe(struct platform_device *pdev)
> >  		goto err;
> >  	}
> >  
> > -out:
> > +err:
> > +	return ret;
> > +}
> > +
> > +static int exynos_bus_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct device_node *np = dev->of_node, *node;
> > +	struct devfreq_dev_profile *profile;
> > +	struct exynos_bus *bus;
> > +	int ret, max_state;
> > +	unsigned long min_freq, max_freq;
> > +	bool passive = false;
> > +
> > +	if (!np) {
> > +		dev_err(dev, "failed to find devicetree node\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
> > +	if (!bus)
> > +		return -ENOMEM;
> > +	mutex_init(&bus->lock);
> > +	bus->dev = &pdev->dev;
> > +	platform_set_drvdata(pdev, bus);
> > +
> > +	profile = devm_kzalloc(dev, sizeof(*profile), GFP_KERNEL);
> > +	if (!profile)
> > +		return -ENOMEM;
> > +
> > +	node = of_parse_phandle(dev->of_node, "devfreq", 0);
> > +	if (node) {
> > +		of_node_put(node);
> > +		passive = true;
> > +	} else {
> > +		ret = exynos_bus_parent_parse_of(np, bus);
> > +		if (ret < 0)
> > +			return ret;
> > +	}
> > +
> > +	/* Parse the device-tree to get the resource information */
> > +	ret = exynos_bus_parse_of(np, bus);
> > +	if (ret < 0)
> > +		goto err_reg;
> > +
> > +	if (passive)
> > +		ret = exynos_bus_profile_init_passive(bus, profile);
> > +	else
> > +		ret = exynos_bus_profile_init(bus, profile);
> > +
> > +	if (ret < 0)
> > +		goto err;
> > +
> >  	max_state = bus->devfreq->profile->max_state;
> >  	min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
> >  	max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
> > 
> > 
> > 
> > 
> 
> 
-- 
Artur Świgoń
Samsung R&D Institute Poland
Samsung Electronics



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 00/21] Refine memblock API
From: Mike Rapoport @ 2019-09-25  6:42 UTC (permalink / raw)
  To: Adam Ford
  Cc: Linux Kernel Mailing List, etnaviv, linux-mm, Russell King,
	linux-arm-kernel, Lucas Stach
In-Reply-To: <CAHCN7x+Jv7yGPoB0Gm=TJ30ObLJduw2XomHkd++KqFEURYQcGg@mail.gmail.com>

(updated CC)

Hi,

On Tue, Sep 24, 2019 at 12:52:35PM -0500, Adam Ford wrote:
> On Mon, Jan 21, 2019 at 2:05 AM Mike Rapoport <rppt@linux.ibm.com> wrote:
> >
> > Hi,
> >
> > v2 changes:
> > * replace some more %lu with %zu
> > * remove panics where they are not needed in s390 and in printk
> > * collect Acked-by and Reviewed-by.
> >
> >
> > Christophe Leroy (1):
> >   powerpc: use memblock functions returning virtual address
> >
> > Mike Rapoport (20):
> >   openrisc: prefer memblock APIs returning virtual address
> >   memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc
> >   memblock: drop memblock_alloc_base_nid()
> >   memblock: emphasize that memblock_alloc_range() returns a physical address
> >   memblock: memblock_phys_alloc_try_nid(): don't panic
> >   memblock: memblock_phys_alloc(): don't panic
> >   memblock: drop __memblock_alloc_base()
> >   memblock: drop memblock_alloc_base()
> >   memblock: refactor internal allocation functions
> >   memblock: make memblock_find_in_range_node() and choose_memblock_flags() static
> >   arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0)
> >   arch: don't memset(0) memory returned by memblock_alloc()
> >   ia64: add checks for the return value of memblock_alloc*()
> >   sparc: add checks for the return value of memblock_alloc*()
> >   mm/percpu: add checks for the return value of memblock_alloc*()
> >   init/main: add checks for the return value of memblock_alloc*()
> >   swiotlb: add checks for the return value of memblock_alloc*()
> >   treewide: add checks for the return value of memblock_alloc*()
> >   memblock: memblock_alloc_try_nid: don't panic
> >   memblock: drop memblock_alloc_*_nopanic() variants
> >
> I know it's rather late, but this patch broke the Etnaviv 3D graphics
> in my i.MX6Q.
 
Can you identify the exact patch from the series that caused the
regression?

> When I try to use the 3D, it returns some errors and the dmesg log
> shows some memory allocation errors too:
> [    3.682347] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)
> [    3.688669] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
> [    3.695099] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops)
> [    3.700800] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
> [    3.723013] etnaviv-gpu 130000.gpu: command buffer outside valid
> memory window
> [    3.731308] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
> [    3.752437] etnaviv-gpu 134000.gpu: command buffer outside valid
> memory window
> [    3.760583] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
> [    3.766766] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
> [    3.776131] [drm] Initialized etnaviv 1.2.0 20151214 for etnaviv on minor 0
> 
> # glmark2-es2-drm
> Error creating gpu
> Error: eglCreateWindowSurface failed with error: 0x3009
> Error: eglCreateWindowSurface failed with error: 0x3009
> Error: CanvasGeneric: Invalid EGL state
> Error: main: Could not initialize canvas
> 
> 
> Before this patch:
> 
> [    3.691995] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops)
> [    3.698356] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops)
> [    3.704792] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops)
> [    3.710488] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
> [    3.733649] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
> [    3.756115] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
> [    3.762250] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
> [    3.771432] [drm] Initialized etnaviv 1.2.0 20151214 for etnaviv on minor 0
> 
> and the 3D gemos work without this.
> 
> I don't know enough about the i.MX6 nor the 3D accelerator to know how
> to fix it.
> I am hoping someone in the know might have some suggestions.

Can you please add "memblock=debug" to your kernel command line and send
kernel logs for both working and failing versions? 

-- 
Sincerely yours,
Mike.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH v2 00/11] Simple QoS for exynos-bus driver using interconnect
From: Chanwoo Choi @ 2019-09-25  6:48 UTC (permalink / raw)
  To: Artur Świgoń, devicetree, linux-arm-kernel,
	linux-samsung-soc, linux-kernel, linux-pm, dri-devel
  Cc: b.zolnierkie, k.konieczny, sw0312.kim, krzk, inki.dae,
	myungjoo.ham, cpgs (cpgs@samsung.com), leonard.crestez,
	georgi.djakov, m.szyprowski
In-Reply-To: <f7387513d3c11cea7a7d35652457c1e7d7fed009.camel@samsung.com>

Hi,

On 19. 9. 25. 오후 3:37, Artur Świgoń wrote:
> On Wed, 2019-09-25 at 15:12 +0900, Chanwoo Choi wrote:
>> Hi,
>>
>> On 19. 9. 25. 오후 2:47, Artur Świgoń wrote:
>>> Hi,
>>>
>>> On Fri, 2019-09-20 at 11:14 +0900, Chanwoo Choi wrote:
>>>> Hi Artur,
>>>>
>>>> I tried to just build this patch on mainline kernel or linux-next.
>>>> But, when I applied them, merge conflict happens. You didn't develop
>>>> them on latest version. Please rebase them based on latest mainline kernel.
>>>
>>> I developed on top of next-20190918 on which I applied
>>> https://patchwork.kernel.org/cover/11149497/ as I mentioned in the cover
>>> letter. The dev_pm_qos patches and my RFC have just cleanly rebased together on
>>> top of next-20190920. Could you check if you have the dev_pm_qos patches (v5,
>>> the version number is missing in this one; link above) and if so, where does the
>>> conflict appear?
>>
>> I faced on the merge conflict of drivers/devfreq/exynos-bus.c.
>> I think that It is not related to to dev_pm_qos patch.
> 
> I think that it is actually related to the specific version of dev_pm_qos (v5) that
> I used because patch 08/08 of dev_pm_qos series modifies exynos_bus_probe() in
> drivers/devfreq/exynos-bus.c (https://patchwork.kernel.org/patch/11149507/).
> 
> I will rebase the next RFC (v3) on latest dev_pm_qos patches from Leonard and the
> latest Linux-next kernel.

My mistake. I only checked the Leonard's latest patches(v8)
which doesn't contain this patch. OK. I'll try again. Thanks.
[1] https://patchwork.kernel.org/patch/11149507/
- PM / devfreq: Move opp notifier registration to core

> 
>> Maybe, Kamil's patches[1] changed the many things of exynos-bus.c
>> If your test branch doesn't contain following patches, 
>> you need to rebase your patches based on latest mainline kernel 
>> from Linus Torvald.
>> [1] https://patchwork.kernel.org/cover/11083663/
>> - [RESEND PATCH v5 0/4] add coupled regulators for Exynos5422/5800
> 
> Yes, requiring Kamil's patches is one of the changes in this RFC (v2), since they
> are already merged.
> 
>> Today, I tried to apply these patch again based on latest mainline kernel.
>> The merge conflict happen still.
>>
>> - merge conflict log
>> Applying: devfreq: exynos-bus: Extract exynos_bus_profile_init()
>> error: patch failed: drivers/devfreq/exynos-bus.c:334
>> error: drivers/devfreq/exynos-bus.c: patch does not apply
>> Patch failed at 0001 devfreq: exynos-bus: Extract exynos_bus_profile_init()
>>
>>
>>>
>>>> On 19. 9. 20. 오전 10:07, Chanwoo Choi wrote:
>>>>> Hi Artur,
>>>>>
>>>>> On v1, I mentioned that we need to discuss how to change
>>>>> the v2 for this. But, I have not received any reply from you on v1.
>>>>> And, without your reply from v1, you just send v2.
>>>>>
>>>>> I think that it is not proper development sequence.
>>>>> I have spent many times to review your patches
>>>>> and also I'll review your patches. You have to take care
>>>>> the reply of reviewer and and keep the basic rule
>>>>> of mailing contribution for discussion.
>>>>>
>>>>> On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
>>>>>> The following patchset adds interconnect[1][2] framework support to the
>>>>>> exynos-bus devfreq driver. Extending the devfreq driver with interconnect
>>>>>> capabilities started as a response to the issue referenced in [3]. The
>>>>>> patches can be subdivided into four logical groups:
>>>>>>
>>>>>> (a) Refactoring the existing devfreq driver in order to improve readability
>>>>>> and accommodate for adding new code (patches 01--04/11).
>>>>>>
>>>>>> (b) Tweaking the interconnect framework to support the exynos-bus use case
>>>>>> (patches 05--07/11). Exporting of_icc_get_from_provider() allows us to
>>>>>> avoid hardcoding every single graph edge in the DT or driver source, and
>>>>>> relaxing the requirement contained in that function removes the need to
>>>>>> provide dummy node IDs in the DT. Adjusting the logic in
>>>>>> apply_constraints() (drivers/interconnect/core.c) accounts for the fact
>>>>>> that every bus is a separate entity and therefore a separate interconnect
>>>>>> provider, albeit constituting a part of a larger hierarchy.
>>>>>>
>>>>>> (c) Implementing interconnect providers in the exynos-bus devfreq driver
>>>>>> and adding required DT properties for one selected platform, namely
>>>>>> Exynos4412 (patches 08--09/11). Due to the fact that this aims to be a
>>>>>> generic driver for various Exynos SoCs, node IDs are generated dynamically
>>>>>> rather than hardcoded. This has been determined to be a simpler approach,
>>>>>> but depends on changes described in (b).
>>>>>>
>>>>>> (d) Implementing a sample interconnect consumer for exynos-mixer targeted
>>>>>> at the issue referenced in [3], again with DT info only for Exynos4412
>>>>>> (patches 10--11/11).
>>>>>>
>>>>>> Integration of devfreq and interconnect functionalities is achieved by
>>>>>> using dev_pm_qos_*() API[5]. All new code works equally well when
>>>>>> CONFIG_INTERCONNECT is 'n' (as in exynos_defconfig) in which case all
>>>>>> interconnect API functions are no-ops.
>>>>>>
>>>>>> This patchset depends on [5].
>>>>>>
>>>>>> --- Changes since v1 [6]:
>>>>>> * Rebase on [4] (coupled regulators).
>>>>>> * Rebase on [5] (dev_pm_qos for devfreq).
>>>>>> * Use dev_pm_qos_*() API[5] instead of overriding frequency in
>>>>>>   exynos_bus_target().
>>>>>> * Use IDR for node ID allocation.
>>>>>> * Avoid goto in functions extracted in patches 01 & 02 (cf. patch 04).
>>>>>> * Reverse order of multiplication and division in
>>>>>>   mixer_set_memory_bandwidth() (patch 11) to avoid integer overflow.
>>>>>>
>>>>>> ---
>>>>>> Artur Świgoń
>>>>>> Samsung R&D Institute Poland
>>>>>> Samsung Electronics
>>>>>>
>>>>>> ---
>>>>>> References:
>>>>>> [1] Documentation/interconnect/interconnect.rst
>>>>>> [2] Documentation/devicetree/bindings/interconnect/interconnect.txt
>>>>>> [3] https://patchwork.kernel.org/patch/10861757/ (original issue)
>>>>>> [4] https://patchwork.kernel.org/cover/11083663/ (coupled regulators; merged)
>>>>>> [5] https://patchwork.kernel.org/cover/11149497/ (dev_pm_qos for devfreq)
>>>>>> [6] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC)
>>>>>>
>>>>>> Artur Świgoń (10):
>>>>>>   devfreq: exynos-bus: Extract exynos_bus_profile_init()
>>>>>>   devfreq: exynos-bus: Extract exynos_bus_profile_init_passive()
>>>>>>   devfreq: exynos-bus: Change goto-based logic to if-else logic
>>>>>>   devfreq: exynos-bus: Clean up code
>>>>>>   interconnect: Export of_icc_get_from_provider()
>>>>>>   interconnect: Relax requirement in of_icc_get_from_provider()
>>>>>>   interconnect: Relax condition in apply_constraints()
>>>>>>   arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
>>>>>>   devfreq: exynos-bus: Add interconnect functionality to exynos-bus
>>>>>>   arm: dts: exynos: Add interconnects to Exynos4412 mixer
>>>>>>
>>>>>> Marek Szyprowski (1):
>>>>>>   drm: exynos: mixer: Add interconnect support
>>>>>>
>>>>>>  .../boot/dts/exynos4412-odroid-common.dtsi    |   1 +
>>>>>>  arch/arm/boot/dts/exynos4412.dtsi             |  10 +
>>>>>>  drivers/devfreq/exynos-bus.c                  | 319 +++++++++++++-----
>>>>>>  drivers/gpu/drm/exynos/exynos_mixer.c         |  71 +++-
>>>>>>  drivers/interconnect/core.c                   |  12 +-
>>>>>>  include/linux/interconnect-provider.h         |   6 +
>>>>>>  6 files changed, 327 insertions(+), 92 deletions(-)
>>>>>>
> 
> 
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v1] ARM: Add support for Realtek SOC
From: James Tai @ 2019-09-25  6:43 UTC (permalink / raw)
  To: 'Masahiro Yamada', 'Arnd Bergmann'
  Cc: 'Jason A . Donenfeld', CY_Huang[黃鉦晏],
	'Linus Walleij', 'Stefan Agner',
	'Benjamin Gaignard', Simon Hsu[徐文翰],
	'Mauro Carvalho Chehab',
	Tom Ting[丁郁庭],
	Jim Tsai [蔡維晉], Phinex Hung,
	Edward Wu[吳奕寬], 'Rob Herring',
	'Lorenzo Pieralisi', 'Russell King',
	'Mike Rapoport', YH_Hsieh[謝宇勳],
	TY_Chang[張子逸], 'Thierry Reding',
	'jamestai.sky@gmail.com',
	ZR_Chen[陳振榮], Hau, Yukuen,
	Jinn.Cheng[鄭才進],
	Chase Yen [顏呈育],
	Stanley Chang[昌育德], 'Doug Anderson',
	'Linux ARM', Eric Wang[王偉全], Adklei,
	James Tai, Edgar Lee [李承諭],
	'Ard Biesheuvel', PK.Chuang [莊博凱],
	'Nicolas Pitre', 'Nick Desaulniers',
	'linux-kernel@vger.kernel.org', 'Paul Burton',
	phelic, 'Andreas Färber'

From: "james.tai" <james.tai@realtek.com>

This patch adds the basic machine file for
the Realtek RTD16XX and RTD13XX platform.

Signed-off-by: james.tai <james.tai@realtek.com>
---
Changes since last version:
	- Add RTD13XX platform.
	- Add PSCI support.
	- Add ARCH_MULTI_V7 config.
	- remove 'textofs-$(CONFIG_ARCH_REALTEK) := 0x00208000' from 
	  'arch/arm/Makefile'.
	- remove map_io,init_time,init_machine and smp_init from machine
	  descriptor.
---
 arch/arm/Kconfig                |  2 ++
 arch/arm/Makefile               |  1 +
 arch/arm/mach-realtek/Kconfig   | 20 +++++++++++++
 arch/arm/mach-realtek/Makefile  |  3 ++
 arch/arm/mach-realtek/platsmp.c | 51 +++++++++++++++++++++++++++++++++
 arch/arm/mach-realtek/platsmp.h |  6 ++++
 arch/arm/mach-realtek/realtek.c | 43 +++++++++++++++++++++++++++
 7 files changed, 126 insertions(+)
 create mode 100644 arch/arm/mach-realtek/Kconfig
 create mode 100644 arch/arm/mach-realtek/Makefile
 create mode 100644 arch/arm/mach-realtek/platsmp.c
 create mode 100644 arch/arm/mach-realtek/platsmp.h
 create mode 100644 arch/arm/mach-realtek/realtek.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..1f7967c97267 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -793,6 +793,8 @@ source "arch/arm/mach-realview/Kconfig"
 
 source "arch/arm/mach-rockchip/Kconfig"
 
+source "arch/arm/mach-realtek/Kconfig"
+
 source "arch/arm/mach-s3c24xx/Kconfig"
 
 source "arch/arm/mach-s3c64xx/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c3624ca6c0bc..560ae7d72aab 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -205,6 +205,7 @@ machine-$(CONFIG_ARCH_RDA)		+= rda
 machine-$(CONFIG_ARCH_REALVIEW)		+= realview
 machine-$(CONFIG_ARCH_ROCKCHIP)		+= rockchip
 machine-$(CONFIG_ARCH_RPC)		+= rpc
+machine-$(CONFIG_ARCH_REALTEK)		+= realtek
 machine-$(CONFIG_ARCH_S3C24XX)		+= s3c24xx
 machine-$(CONFIG_ARCH_S3C64XX)		+= s3c64xx
 machine-$(CONFIG_ARCH_S5PV210)		+= s5pv210
diff --git a/arch/arm/mach-realtek/Kconfig b/arch/arm/mach-realtek/Kconfig
new file mode 100644
index 000000000000..a638f4322bb2
--- /dev/null
+++ b/arch/arm/mach-realtek/Kconfig
@@ -0,0 +1,20 @@
+# SPDX-License-Identifier: GPL-2.0-only
+menuconfig ARCH_REALTEK
+	bool "Realtek SoC Support"
+	depends on ARCH_MULTI_V7
+	help
+	  Support for Realtek rtd16xx & rtd13xx SoCs.
+
+if ARCH_REALTEK
+
+config ARCH_RTD13XX
+	bool "Enable support for RTD1319"
+	select ARM_GIC_V3
+	select ARM_PSCI
+
+config ARCH_RTD16XX
+	bool "Enable support for RTD1619"
+	select ARM_GIC_V3
+	select ARM_PSCI
+
+endif
diff --git a/arch/arm/mach-realtek/Makefile b/arch/arm/mach-realtek/Makefile
new file mode 100644
index 000000000000..9cdc1f1f2917
--- /dev/null
+++ b/arch/arm/mach-realtek/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_ARCH_REALTEK) += realtek.o
+obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-realtek/platsmp.c b/arch/arm/mach-realtek/platsmp.c
new file mode 100644
index 000000000000..b3fc99447ad4
--- /dev/null
+++ b/arch/arm/mach-realtek/platsmp.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2019 Realtek Semiconductor Corp.
+ */
+
+#include <linux/init.h>
+#include <linux/delay.h>
+#include <linux/jiffies.h>
+#include <linux/io.h>
+#include <linux/memory.h>
+#include <linux/smp.h>
+#include <linux/of.h>
+#include <linux/arm-smccc.h>
+#include <asm/smp_plat.h>
+#include <asm/cacheflush.h>
+#include <asm/cp15.h>
+#include <asm/barrier.h>
+
+#define BL31_CMD 0x8400ff04
+#define BL31_DAT 0x00001619
+#define CORE_PWRDN_EN 0x1
+
+#define CPUPWRCTLR __ACCESS_CP15(c15, 0, c2, 7)
+
+#ifdef CONFIG_HOTPLUG_CPU
+
+static void rtk_cpu_die(unsigned int cpu)
+{
+	struct arm_smccc_res res;
+	unsigned int cpu_pwr_ctrl;
+
+	/* notify BL31 cpu hotplug */
+	arm_smccc_smc(BL31_CMD, BL31_DAT, 0, 0, 0, 0, 0, 0, &res);
+	v7_exit_coherency_flush(louis);
+
+	cpu_pwr_ctrl = read_sysreg(CPUPWRCTLR);
+	cpu_pwr_ctrl |= CORE_PWRDN_EN;
+	write_sysreg(cpu_pwr_ctrl, CPUPWRCTLR);
+
+	dsb(sy);
+
+	for (;;)
+		wfi();
+}
+#endif
+
+struct smp_operations rtk_smp_ops __initdata = {
+#ifdef CONFIG_HOTPLUG_CPU
+	.cpu_die = rtk_cpu_die,
+#endif
+};
diff --git a/arch/arm/mach-realtek/platsmp.h b/arch/arm/mach-realtek/platsmp.h
new file mode 100644
index 000000000000..c9c4d712369c
--- /dev/null
+++ b/arch/arm/mach-realtek/platsmp.h
@@ -0,0 +1,6 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2019 Realtek Semiconductor Corp.
+ */
+
+extern struct smp_operations rtk_smp_ops;
diff --git a/arch/arm/mach-realtek/realtek.c b/arch/arm/mach-realtek/realtek.c
new file mode 100644
index 000000000000..2692ac53f59b
--- /dev/null
+++ b/arch/arm/mach-realtek/realtek.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2019 Realtek Semiconductor Corp.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clocksource.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/irqchip.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/io.h>
+#include <linux/memblock.h>
+#include <linux/delay.h>
+#include <linux/clockchips.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/system_misc.h>
+#include <asm/system_info.h>
+
+#include "platsmp.h"
+
+static const char *const rtd13xx_board_dt_compat[] = {
+	"realtek,rtd1319",
+	NULL,
+};
+
+static const char *const rtd16xx_board_dt_compat[] = {
+	"realtek,rtd1619",
+	NULL,
+};
+
+DT_MACHINE_START(RTD13XX, "Realtek rtd13xx platform")
+	.dt_compat = rtd13xx_board_dt_compat,
+	.smp = smp_ops(rtk_smp_ops),
+MACHINE_END
+
+DT_MACHINE_START(RTD16XX, "Realtek rtd16xx platform")
+	.dt_compat = rtd16xx_board_dt_compat,
+	.smp = smp_ops(rtk_smp_ops),
+MACHINE_END
-- 
2.17.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [RFC PATCH 00/12] Add SDEI support for arm64
From: no-reply @ 2019-09-25  6:54 UTC (permalink / raw)
  To: guoheyi
  Cc: mark.rutland, peter.maydell, marc.zyngier, qemu-devel,
	Dave.Martin, qemu-arm, james.morse, guoheyi, wanghaibin.wang,
	kvmarm, linux-arm-kernel
In-Reply-To: <1569338511-3572-1-git-send-email-guoheyi@huawei.com>

Patchew URL: https://patchew.org/QEMU/1569338511-3572-1-git-send-email-guoheyi@huawei.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

libudev           no
default devices   yes

warning: Python 2 support is deprecated
warning: Python 3 will be required for building future versions of QEMU
cross containers  no

NOTE: guest cross-compilers enabled: cc
---
  LINK    aarch64-softmmu/qemu-system-aarch64
hw/arm/virt-acpi-build.o: In function `virt_acpi_build':
/tmp/qemu-test/src/hw/arm/virt-acpi-build.c:810: undefined reference to `sdei_enabled'
collect2: error: ld returned 1 exit status
make[1]: *** [qemu-system-aarch64] Error 1
make: *** [aarch64-softmmu/all] Error 2
Traceback (most recent call last):


The full log is available at
http://patchew.org/logs/1569338511-3572-1-git-send-email-guoheyi@huawei.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH 00/12] Add SDEI support for arm64
From: no-reply @ 2019-09-25  6:58 UTC (permalink / raw)
  To: guoheyi
  Cc: mark.rutland, peter.maydell, marc.zyngier, qemu-devel,
	Dave.Martin, qemu-arm, james.morse, guoheyi, wanghaibin.wang,
	kvmarm, linux-arm-kernel
In-Reply-To: <1569338511-3572-1-git-send-email-guoheyi@huawei.com>

Patchew URL: https://patchew.org/QEMU/1569338511-3572-1-git-send-email-guoheyi@huawei.com/



Hi,

This series failed the docker-mingw@fedora build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#! /bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===

  CC      aarch64-softmmu/hw/arm/tosa.o
  CC      aarch64-softmmu/hw/arm/z2.o
In file included from /tmp/qemu-test/src/hw/arm/virt-acpi-build.c:35:
/tmp/qemu-test/src/target/arm/sdei.h:26:10: fatal error: linux/kvm.h: No such file or directory
 #include <linux/kvm.h>
          ^~~~~~~~~~~~~
compilation terminated.


The full log is available at
http://patchew.org/logs/1569338511-3572-1-git-send-email-guoheyi@huawei.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH v2 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
From: Chanwoo Choi @ 2019-09-25  7:03 UTC (permalink / raw)
  To: Artur Świgoń, devicetree, linux-arm-kernel,
	linux-samsung-soc, linux-kernel, linux-pm, dri-devel
  Cc: Artur Świgoń, b.zolnierkie, sw0312.kim, krzk, inki.dae,
	myungjoo.ham, leonard.crestez, georgi.djakov, m.szyprowski
In-Reply-To: <20190919142236.4071-10-a.swigon@samsung.com>

Hi,

I need the time to dig the ICC framework
to understand them detailed. After that, I'll review this.

Basically, I agree this approach. But, I'm wondering
the existing binding method between 'bus_leftbus' and 'bus_dmc'.
From before, I thought that devfreq framework need to
enhance the binding method between parent devfreq device
and passive devfreq device instead of 'devfreq' property.

On this patch, use the same binding way between
'bus_leftbus' and 'bus_dmc' with 'parent' property
as following:

+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -106,6 +106,7 @@
 &bus_leftbus {
 	devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
 	vdd-supply = <&buck3_reg>;
+	parent = <&bus_dmc>;
 	status = "okay";
 };

I'm not sure about continuing to use this method for new feature.
If possible, hope to replace the existing binding style
with new method like of_graph. Actually, I don't know the correct method.


On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> From: Artur Świgoń <a.swigon@partner.samsung.com>
> 
> This patch adds interconnect functionality to the exynos-bus devfreq
> driver.
> 
> The SoC topology is a graph (or, more specifically, a tree) and most of
> its edges are taken from the devfreq parent-child hierarchy (cf.
> Documentation/devicetree/bindings/devfreq/exynos-bus.txt). Due to
> unspecified relative probing order, -EPROBE_DEFER may be propagated to
> guarantee that a child is probed before its parent.
> 
> Each bus is now an interconnect provider and an interconnect node as well
> (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
> itself as a node. Node IDs are not hardcoded but rather assigned at
> runtime, in probing order (subject to the above-mentioned exception
> regarding relative order). This approach allows for using this driver with
> various Exynos SoCs.
> 
> Frequencies requested via the interconnect API for a given node are
> propagated to devfreq using dev_pm_qos_update_request(). Please note that
> it is not an error when CONFIG_INTERCONNECT is 'n', in which case all
> interconnect API functions are no-op.
> 
> Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
> ---
>  drivers/devfreq/exynos-bus.c | 153 +++++++++++++++++++++++++++++++++++
>  1 file changed, 153 insertions(+)
> 
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 8d44810cac69..e0232202720d 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -14,14 +14,19 @@
>  #include <linux/devfreq-event.h>
>  #include <linux/device.h>
>  #include <linux/export.h>
> +#include <linux/idr.h>
> +#include <linux/interconnect-provider.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/pm_opp.h>
> +#include <linux/pm_qos.h>
>  #include <linux/platform_device.h>
>  #include <linux/regulator/consumer.h>
>  
>  #define DEFAULT_SATURATION_RATIO	40
>  
> +#define icc_units_to_khz(x) ((x) / 8)
> +
>  struct exynos_bus {
>  	struct device *dev;
>  
> @@ -35,6 +40,12 @@ struct exynos_bus {
>  	struct opp_table *opp_table;
>  	struct clk *clk;
>  	unsigned int ratio;
> +
> +	/* One provider per bus, one node per provider */
> +	struct icc_provider provider;
> +	struct icc_node *node;
> +
> +	struct dev_pm_qos_request qos_req;
>  };
>  
>  /*
> @@ -59,6 +70,13 @@ exynos_bus_ops_edev(enable_edev);
>  exynos_bus_ops_edev(disable_edev);
>  exynos_bus_ops_edev(set_event);
>  
> +static int exynos_bus_next_id(void)
> +{
> +	static DEFINE_IDA(exynos_bus_icc_ida);
> +
> +	return ida_alloc(&exynos_bus_icc_ida, GFP_KERNEL);
> +}
> +
>  static int exynos_bus_get_event(struct exynos_bus *bus,
>  				struct devfreq_event_data *edata)
>  {
> @@ -171,6 +189,38 @@ static void exynos_bus_passive_exit(struct device *dev)
>  	clk_disable_unprepare(bus->clk);
>  }
>  
> +static int exynos_bus_icc_set(struct icc_node *src, struct icc_node *dst)
> +{
> +	struct exynos_bus *src_bus = src->data, *dst_bus = dst->data;
> +	s32 src_freq = icc_units_to_khz(src->avg_bw);
> +	s32 dst_freq = icc_units_to_khz(dst->avg_bw);
> +
> +	dev_pm_qos_update_request(&src_bus->qos_req, src_freq);
> +	dev_pm_qos_update_request(&dst_bus->qos_req, dst_freq);
> +
> +	return 0;
> +}
> +
> +static int exynos_bus_icc_aggregate(struct icc_node *node, u32 tag, u32 avg_bw,
> +				    u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
> +{
> +	*agg_avg += avg_bw;
> +	*agg_peak = max(*agg_peak, peak_bw);
> +
> +	return 0;
> +}
> +
> +static struct icc_node *exynos_bus_icc_xlate(struct of_phandle_args *spec,
> +					     void *data)
> +{
> +	struct exynos_bus *bus = data;
> +
> +	if (spec->np != bus->dev->of_node)
> +		return ERR_PTR(-EINVAL);
> +
> +	return bus->node;
> +}
> +
>  static int exynos_bus_parent_parse_of(struct device_node *np,
>  					struct exynos_bus *bus)
>  {
> @@ -366,6 +416,101 @@ static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
>  	return 0;
>  }
>  
> +static int exynos_bus_icc_connect(struct exynos_bus *bus)
> +{
> +	struct device_node *np = bus->dev->of_node;
> +	struct devfreq *parent_devfreq;
> +	struct icc_node *parent_node = NULL;
> +	struct of_phandle_args args;
> +	int ret = 0;
> +
> +	parent_devfreq = devfreq_get_devfreq_by_phandle(bus->dev, 0);
> +	if (!IS_ERR(parent_devfreq)) {
> +		struct exynos_bus *parent_bus;
> +
> +		parent_bus = dev_get_drvdata(parent_devfreq->dev.parent);
> +		parent_node = parent_bus->node;
> +	} else {
> +		/* Look for parent in DT */
> +		int num = of_count_phandle_with_args(np, "parent",
> +						     "#interconnect-cells");
> +		if (num != 1)
> +			goto out; /* 'parent' is optional */
> +
> +		ret = of_parse_phandle_with_args(np, "parent",
> +						 "#interconnect-cells",
> +						 0, &args);
> +		if (ret < 0)
> +			goto out;
> +
> +		of_node_put(args.np);
> +
> +		parent_node = of_icc_get_from_provider(&args);
> +		if (IS_ERR(parent_node)) {
> +			/* May be -EPROBE_DEFER */
> +			ret = PTR_ERR(parent_node);
> +			goto out;
> +		}
> +	}



> +
> +	ret = icc_link_create(bus->node, parent_node->id);
> +
> +out:
> +	return ret;
> +}
> +
> +static int exynos_bus_icc_init(struct exynos_bus *bus)
> +{
> +	struct device *dev = bus->dev;
> +	struct icc_provider *provider = &bus->provider;
> +	struct icc_node *node;
> +	int id, ret;
> +
> +	/* Initialize the interconnect provider */
> +	provider->set = exynos_bus_icc_set;
> +	provider->aggregate = exynos_bus_icc_aggregate;
> +	provider->xlate = exynos_bus_icc_xlate;
> +	provider->dev = dev;
> +	provider->data = bus;
> +
> +	ret = icc_provider_add(provider);
> +	if (ret < 0)
> +		goto out;
> +
> +	ret = id = exynos_bus_next_id();
> +	if (ret < 0)
> +		goto err_node;
> +
> +	node = icc_node_create(id);
> +	if (IS_ERR(node)) {
> +		ret = PTR_ERR(node);
> +		goto err_node;
> +	}
> +
> +	bus->node = node;
> +	node->name = dev->of_node->name;
> +	node->data = bus;
> +	icc_node_add(node, provider);
> +
> +	ret = exynos_bus_icc_connect(bus);
> +	if (ret < 0)
> +		goto err_connect;
> +
> +	ret = dev_pm_qos_add_request(bus->devfreq->dev.parent, &bus->qos_req,
> +				     DEV_PM_QOS_MIN_FREQUENCY, 0);
> +
> +out:
> +	return ret;
> +
> +err_connect:
> +	icc_node_del(node);
> +	icc_node_destroy(id);
> +err_node:
> +	icc_provider_del(provider);
> +
> +	return ret;
> +}
> +
>  static int exynos_bus_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -415,6 +560,14 @@ static int exynos_bus_probe(struct platform_device *pdev)
>  	if (ret < 0)
>  		goto err;
>  
> +	/*
> +	 * Initialize interconnect provider. A return value of -ENOTSUPP means
> +	 * that CONFIG_INTERCONNECT is disabled.
> +	 */
> +	ret = exynos_bus_icc_init(bus);
> +	if (ret < 0 && ret != -ENOTSUPP)
> +		goto err;
> +
>  	max_state = bus->devfreq->profile->max_state;
>  	min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
>  	max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH v2 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
From: Artur Świgoń @ 2019-09-25  7:12 UTC (permalink / raw)
  To: Chanwoo Choi, devicetree, linux-arm-kernel, linux-samsung-soc,
	linux-kernel, linux-pm, dri-devel
  Cc: b.zolnierkie, sw0312.kim, Artur Świgoń, krzk, inki.dae,
	myungjoo.ham, leonard.crestez, georgi.djakov, m.szyprowski
In-Reply-To: <e004bedd-294b-172b-5e34-bf7afcfd04bc@samsung.com>

Hi,

On Wed, 2019-09-25 at 16:03 +0900, Chanwoo Choi wrote:
> Hi,
> 
> I need the time to dig the ICC framework
> to understand them detailed. After that, I'll review this.
> 
> Basically, I agree this approach. But, I'm wondering
> the existing binding method between 'bus_leftbus' and 'bus_dmc'.
> From before, I thought that devfreq framework need to
> enhance the binding method between parent devfreq device
> and passive devfreq device instead of 'devfreq' property.
> 
> On this patch, use the same binding way between
> 'bus_leftbus' and 'bus_dmc' with 'parent' property
> as following:
> 
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -106,6 +106,7 @@
>  &bus_leftbus {
>  	devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
>  	vdd-supply = <&buck3_reg>;
> +	parent = <&bus_dmc>;
>  	status = "okay";
>  };
> 
> I'm not sure about continuing to use this method for new feature.
> If possible, hope to replace the existing binding style
> with new method like of_graph. Actually, I don't know the correct method.

Adding the 'parent' binding was the simplest solution to create this
RFC to show the concept of using interconnect functionality in devfreq.
I agree that a method like of_graph is probably more elegant. I am open
to suggestions.

> On 19. 9. 19. 오후 11:22, Artur Świgoń wrote:
> > From: Artur Świgoń <a.swigon@partner.samsung.com>
> > 
> > This patch adds interconnect functionality to the exynos-bus devfreq
> > driver.
> > 
> > The SoC topology is a graph (or, more specifically, a tree) and most of
> > its edges are taken from the devfreq parent-child hierarchy (cf.
> > Documentation/devicetree/bindings/devfreq/exynos-bus.txt). Due to
> > unspecified relative probing order, -EPROBE_DEFER may be propagated to
> > guarantee that a child is probed before its parent.
> > 
> > Each bus is now an interconnect provider and an interconnect node as well
> > (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
> > itself as a node. Node IDs are not hardcoded but rather assigned at
> > runtime, in probing order (subject to the above-mentioned exception
> > regarding relative order). This approach allows for using this driver with
> > various Exynos SoCs.
> > 
> > Frequencies requested via the interconnect API for a given node are
> > propagated to devfreq using dev_pm_qos_update_request(). Please note that
> > it is not an error when CONFIG_INTERCONNECT is 'n', in which case all
> > interconnect API functions are no-op.
> > 
> > Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
> > ---
> >  drivers/devfreq/exynos-bus.c | 153 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 153 insertions(+)
> > 
> > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > index 8d44810cac69..e0232202720d 100644
> > --- a/drivers/devfreq/exynos-bus.c
> > +++ b/drivers/devfreq/exynos-bus.c
> > @@ -14,14 +14,19 @@
> >  #include <linux/devfreq-event.h>
> >  #include <linux/device.h>
> >  #include <linux/export.h>
> > +#include <linux/idr.h>
> > +#include <linux/interconnect-provider.h>
> >  #include <linux/module.h>
> >  #include <linux/of.h>
> >  #include <linux/pm_opp.h>
> > +#include <linux/pm_qos.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/regulator/consumer.h>
> >  
> >  #define DEFAULT_SATURATION_RATIO	40
> >  
> > +#define icc_units_to_khz(x) ((x) / 8)
> > +
> >  struct exynos_bus {
> >  	struct device *dev;
> >  
> > @@ -35,6 +40,12 @@ struct exynos_bus {
> >  	struct opp_table *opp_table;
> >  	struct clk *clk;
> >  	unsigned int ratio;
> > +
> > +	/* One provider per bus, one node per provider */
> > +	struct icc_provider provider;
> > +	struct icc_node *node;
> > +
> > +	struct dev_pm_qos_request qos_req;
> >  };
> >  
> >  /*
> > @@ -59,6 +70,13 @@ exynos_bus_ops_edev(enable_edev);
> >  exynos_bus_ops_edev(disable_edev);
> >  exynos_bus_ops_edev(set_event);
> >  
> > +static int exynos_bus_next_id(void)
> > +{
> > +	static DEFINE_IDA(exynos_bus_icc_ida);
> > +
> > +	return ida_alloc(&exynos_bus_icc_ida, GFP_KERNEL);
> > +}
> > +
> >  static int exynos_bus_get_event(struct exynos_bus *bus,
> >  				struct devfreq_event_data *edata)
> >  {
> > @@ -171,6 +189,38 @@ static void exynos_bus_passive_exit(struct device *dev)
> >  	clk_disable_unprepare(bus->clk);
> >  }
> >  
> > +static int exynos_bus_icc_set(struct icc_node *src, struct icc_node *dst)
> > +{
> > +	struct exynos_bus *src_bus = src->data, *dst_bus = dst->data;
> > +	s32 src_freq = icc_units_to_khz(src->avg_bw);
> > +	s32 dst_freq = icc_units_to_khz(dst->avg_bw);
> > +
> > +	dev_pm_qos_update_request(&src_bus->qos_req, src_freq);
> > +	dev_pm_qos_update_request(&dst_bus->qos_req, dst_freq);
> > +
> > +	return 0;
> > +}
> > +
> > +static int exynos_bus_icc_aggregate(struct icc_node *node, u32 tag, u32 avg_bw,
> > +				    u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
> > +{
> > +	*agg_avg += avg_bw;
> > +	*agg_peak = max(*agg_peak, peak_bw);
> > +
> > +	return 0;
> > +}
> > +
> > +static struct icc_node *exynos_bus_icc_xlate(struct of_phandle_args *spec,
> > +					     void *data)
> > +{
> > +	struct exynos_bus *bus = data;
> > +
> > +	if (spec->np != bus->dev->of_node)
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	return bus->node;
> > +}
> > +
> >  static int exynos_bus_parent_parse_of(struct device_node *np,
> >  					struct exynos_bus *bus)
> >  {
> > @@ -366,6 +416,101 @@ static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
> >  	return 0;
> >  }
> >  
> > +static int exynos_bus_icc_connect(struct exynos_bus *bus)
> > +{
> > +	struct device_node *np = bus->dev->of_node;
> > +	struct devfreq *parent_devfreq;
> > +	struct icc_node *parent_node = NULL;
> > +	struct of_phandle_args args;
> > +	int ret = 0;
> > +
> > +	parent_devfreq = devfreq_get_devfreq_by_phandle(bus->dev, 0);
> > +	if (!IS_ERR(parent_devfreq)) {
> > +		struct exynos_bus *parent_bus;
> > +
> > +		parent_bus = dev_get_drvdata(parent_devfreq->dev.parent);
> > +		parent_node = parent_bus->node;
> > +	} else {
> > +		/* Look for parent in DT */
> > +		int num = of_count_phandle_with_args(np, "parent",
> > +						     "#interconnect-cells");
> > +		if (num != 1)
> > +			goto out; /* 'parent' is optional */
> > +
> > +		ret = of_parse_phandle_with_args(np, "parent",
> > +						 "#interconnect-cells",
> > +						 0, &args);
> > +		if (ret < 0)
> > +			goto out;
> > +
> > +		of_node_put(args.np);
> > +
> > +		parent_node = of_icc_get_from_provider(&args);
> > +		if (IS_ERR(parent_node)) {
> > +			/* May be -EPROBE_DEFER */
> > +			ret = PTR_ERR(parent_node);
> > +			goto out;
> > +		}
> > +	}
> 
> 
> 
> > +
> > +	ret = icc_link_create(bus->node, parent_node->id);
> > +
> > +out:
> > +	return ret;
> > +}
> > +
> > +static int exynos_bus_icc_init(struct exynos_bus *bus)
> > +{
> > +	struct device *dev = bus->dev;
> > +	struct icc_provider *provider = &bus->provider;
> > +	struct icc_node *node;
> > +	int id, ret;
> > +
> > +	/* Initialize the interconnect provider */
> > +	provider->set = exynos_bus_icc_set;
> > +	provider->aggregate = exynos_bus_icc_aggregate;
> > +	provider->xlate = exynos_bus_icc_xlate;
> > +	provider->dev = dev;
> > +	provider->data = bus;
> > +
> > +	ret = icc_provider_add(provider);
> > +	if (ret < 0)
> > +		goto out;
> > +
> > +	ret = id = exynos_bus_next_id();
> > +	if (ret < 0)
> > +		goto err_node;
> > +
> > +	node = icc_node_create(id);
> > +	if (IS_ERR(node)) {
> > +		ret = PTR_ERR(node);
> > +		goto err_node;
> > +	}
> > +
> > +	bus->node = node;
> > +	node->name = dev->of_node->name;
> > +	node->data = bus;
> > +	icc_node_add(node, provider);
> > +
> > +	ret = exynos_bus_icc_connect(bus);
> > +	if (ret < 0)
> > +		goto err_connect;
> > +
> > +	ret = dev_pm_qos_add_request(bus->devfreq->dev.parent, &bus->qos_req,
> > +				     DEV_PM_QOS_MIN_FREQUENCY, 0);
> > +
> > +out:
> > +	return ret;
> > +
> > +err_connect:
> > +	icc_node_del(node);
> > +	icc_node_destroy(id);
> > +err_node:
> > +	icc_provider_del(provider);
> > +
> > +	return ret;
> > +}
> > +
> >  static int exynos_bus_probe(struct platform_device *pdev)
> >  {
> >  	struct device *dev = &pdev->dev;
> > @@ -415,6 +560,14 @@ static int exynos_bus_probe(struct platform_device *pdev)
> >  	if (ret < 0)
> >  		goto err;
> >  
> > +	/*
> > +	 * Initialize interconnect provider. A return value of -ENOTSUPP means
> > +	 * that CONFIG_INTERCONNECT is disabled.
> > +	 */
> > +	ret = exynos_bus_icc_init(bus);
> > +	if (ret < 0 && ret != -ENOTSUPP)
> > +		goto err;
> > +
> >  	max_state = bus->devfreq->profile->max_state;
> >  	min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
> >  	max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
> > 
> 
> 
-- 
Artur Świgoń
Samsung R&D Institute Poland
Samsung Electronics



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [v1, 1/1] gpio: dts: aspeed: Add SGPIO driver
From: Bartosz Golaszewski @ 2019-09-25  7:31 UTC (permalink / raw)
  To: Hongwei Zhang
  Cc: Mark Rutland, devicetree, Arnd Bergmann, linux-aspeed,
	Bartosz Golaszewski, Andrew Jeffery, Linux Kernel Mailing List,
	Linus Walleij, Ard Biesheuvel, Russell King, Mike Rapoport,
	open list:GPIO SUBSYSTEM, Rob Herring, Joel Stanley,
	Benjamin Gaignard, Mauro Carvalho Chehab, Doug Anderson,
	Andrew Morton, Linux ARM, Masahiro Yamada
In-Reply-To: <1569352021-6383-1-git-send-email-hongweiz@ami.com>

wt., 24 wrz 2019 o 21:07 Hongwei Zhang <hongweiz@ami.com> napisał(a):
>
> Add SGPIO driver support for Aspeed AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
> ---
>  arch/arm/Kconfig                 |  2 ++
>  arch/arm/boot/dts/aspeed-g5.dtsi | 16 +++++++++++++++-
>  drivers/gpio/Kconfig             |  8 ++++++++
>  drivers/gpio/Makefile            |  1 +
>  4 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 2436021..c9f08ab 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1460,6 +1460,8 @@ config ARCH_NR_GPIO
>         default 416 if ARCH_SUNXI
>         default 392 if ARCH_U8500
>         default 352 if ARCH_VT8500
> +       default 312 if MACH_ASPEED_G5
> +       default 304 if MACH_ASPEED_G4
>         default 288 if ARCH_ROCKCHIP
>         default 264 if MACH_H4700
>         default 0
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 00f05bd..85da7ea 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -311,7 +311,7 @@
>                                 #gpio-cells = <2>;
>                                 gpio-controller;
>                                 compatible = "aspeed,ast2500-gpio";
> -                               reg = <0x1e780000 0x1000>;
> +                               reg = <0x1e780000 0x200>;
>                                 interrupts = <20>;
>                                 gpio-ranges = <&pinctrl 0 0 232>;
>                                 clocks = <&syscon ASPEED_CLK_APB>;
> @@ -319,6 +319,20 @@
>                                 #interrupt-cells = <2>;
>                         };
>
> +                       sgpio: sgpio@1e780200 {
> +                               #gpio-cells = <2>;
> +                               compatible = "aspeed,ast2500-sgpio";
> +                               gpio-controller;
> +                               interrupts = <40>;
> +                               reg = <0x1e780200 0x0100>;
> +                               clocks = <&syscon ASPEED_CLK_APB>;
> +                               interrupt-controller;
> +                               ngpios = <8>;
> +                               bus-frequency = <12000000>;
> +                               pinctrl-names = "default";
> +                               pinctrl-0 = <&pinctrl_sgpm_default>;
> +                       };
> +
>                         rtc: rtc@1e781000 {
>                                 compatible = "aspeed,ast2500-rtc";
>                                 reg = <0x1e781000 0x18>;
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index bb13c26..e94f903 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -120,6 +120,14 @@ config GPIO_ASPEED
>         help
>           Say Y here to support Aspeed AST2400 and AST2500 GPIO controllers.
>
> +config SGPIO_ASPEED
> +       bool "Aspeed SGPIO support"
> +       depends on (ARCH_ASPEED || COMPILE_TEST) && OF_GPIO
> +       select GPIO_GENERIC
> +       select GPIOLIB_IRQCHIP
> +       help
> +         Say Y here to support Aspeed AST2500 SGPIO functionality.
> +
>  config GPIO_ATH79
>         tristate "Atheros AR71XX/AR724X/AR913X GPIO support"
>         default y if ATH79
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index a4e9117..bebbd82 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -32,6 +32,7 @@ obj-$(CONFIG_GPIO_AMD_FCH)            += gpio-amd-fch.o
>  obj-$(CONFIG_GPIO_AMDPT)               += gpio-amdpt.o
>  obj-$(CONFIG_GPIO_ARIZONA)             += gpio-arizona.o
>  obj-$(CONFIG_GPIO_ASPEED)              += gpio-aspeed.o
> +obj-$(CONFIG_SGPIO_ASPEED)             += sgpio-aspeed.o
>  obj-$(CONFIG_GPIO_ATH79)               += gpio-ath79.o
>  obj-$(CONFIG_GPIO_BCM_KONA)            += gpio-bcm-kona.o
>  obj-$(CONFIG_GPIO_BD70528)             += gpio-bd70528.o
> --
> 2.7.4
>

This should be split into separate patches with one extending the
binding document and one adding actual support.

Bart

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v1] ARM: config: Add Realtek defconfig
From: James Tai @ 2019-09-25  7:53 UTC (permalink / raw)
  To: 'Arnd Bergmann'
  Cc: pro_dhc_kernel, 'linux-kernel@vger.kernel.org',
	'Linux ARM', 'Russell King'

From: "james.tai" <james.tai@realtek.com>

Add a defconfig for Realtek RTD16XX and RTD13XX platform.

Signed-off-by: james.tai <james.tai@realtek.com>
---
Changes since last version:
	- disable CONFIG_EMBEDDED.
	- disable CONFIG_ARM_THUMBEE.
	- disable CONFIG_SCHED_SMT.
	- disable CONFIG_OABI_COMPAT.
	- disable CONFIG_EFI.
	- disable CONFIG_QORIQ_CPUFREQ.
	- disable CONFIG_NET_DSA.
	- disable CONFIG_CAN.
	- disable CONFIG_CAN_FLEXCAN.
	- disable CONFIG_CAN_RCAR.
	- disable CONFIG_BT.
	- disable CONFIG_BT_HCIUART.
	- disable CONFIG_BT_HCIUART_BCM.
	- disable CONFIG_BT_MRVL.
	- disable CONFIG_BT_MRVL_SDIO.
	- disable CONFIG_MTD.
	- disable CONFIG_MTD_CMDLINE_PARTS.
	- disable CONFIG_MTD_BLOCK.
	- disable CONFIG_MTD_CFI.
	- disable CONFIG_MTD_PHYSMAP.
	- disable CONFIG_MTD_PHYSMAP_OF.
	- disable CONFIG_MTD_RAW_NAND.
	- disable CONFIG_MTD_NAND_DENALI_DT.
	- disable CONFIG_MTD_NAND_BRCMNAND.
	- disable CONFIG_BLK_DEV_RAM_SIZE.
	- disable CONFIG_USB_PEGASUS.
	- disable CONFIG_USB_RTL8152.
	- disable CONFIG_USB_LAN78XX.
	- disable CONFIG_USB_USBNET.
	- disable CONFIG_USB_NET_SMSC75XX.
	- disable CONFIG_USB_NET_SMSC95XX.
	- disable CONFIG_BRCMFMAC.
	- disable CONFIG_MWIFIEX.
	- disable CONFIG_MWIFIEX_SDIO.
	- disable CONFIG_RT2X00.
	- disable CONFIG_RT2800USB.
	- enable CONFIG_NET_VENDOR_3COM.
	- enable CONFIG_NET_VENDOR_ADAPTEC.
	- enable CONFIG_NET_VENDOR_AGERE.
	- enable CONFIG_NET_VENDOR_ALACRITECH.
	- enable CONFIG_NET_VENDOR_ALTEON.
---
 arch/arm/configs/realtek_defconfig | 390 +++++++++++++++++++++++++++++
 1 file changed, 390 insertions(+)
 create mode 100644 arch/arm/configs/realtek_defconfig

diff --git a/arch/arm/configs/realtek_defconfig b/arch/arm/configs/realtek_defconfig
new file mode 100644
index 000000000000..5effebf14c02
--- /dev/null
+++ b/arch/arm/configs/realtek_defconfig
@@ -0,0 +1,390 @@
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_CGROUPS=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_PERF_EVENTS=y
+CONFIG_ARCH_REALTEK=y
+CONFIG_ARCH_RTD13XX=y
+CONFIG_ARCH_RTD16XX=y
+# CONFIG_CACHE_L2X0 is not set
+# CONFIG_ARM_ERRATA_643719 is not set
+CONFIG_ARM_ERRATA_814220=y
+CONFIG_SMP=y
+CONFIG_SCHED_MC=y
+CONFIG_HAVE_ARM_ARCH_TIMER=y
+CONFIG_MCPM=y
+CONFIG_NR_CPUS=6
+CONFIG_HZ_250=y
+CONFIG_HIGHMEM=y
+CONFIG_FORCE_MAX_ZONEORDER=12
+CONFIG_SECCOMP=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_KEXEC=y
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPU_FREQ_GOV_POWERSAVE=m
+CONFIG_CPU_FREQ_GOV_USERSPACE=m
+CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
+CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
+CONFIG_CPUFREQ_DT=y
+CONFIG_CPU_IDLE=y
+CONFIG_ARM_CPUIDLE=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+CONFIG_KERNEL_MODE_NEON=y
+CONFIG_TRUSTED_FOUNDATIONS=y
+CONFIG_EFI_VARS=m
+CONFIG_EFI_CAPSULE_LOADER=m
+CONFIG_ARM_CRYPTO=y
+CONFIG_CRYPTO_SHA1_ARM_NEON=m
+CONFIG_CRYPTO_SHA1_ARM_CE=m
+CONFIG_CRYPTO_SHA2_ARM_CE=m
+CONFIG_CRYPTO_SHA512_ARM=m
+CONFIG_CRYPTO_AES_ARM=m
+CONFIG_CRYPTO_AES_ARM_BS=m
+CONFIG_CRYPTO_AES_ARM_CE=m
+CONFIG_CRYPTO_GHASH_ARM_CE=m
+CONFIG_CRYPTO_CRC32_ARM_CE=m
+CONFIG_CRYPTO_CHACHA20_NEON=m
+CONFIG_JUMP_LABEL=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_CMDLINE_PARTITION=y
+CONFIG_CMA=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_IPV6_ROUTER_PREF=y
+CONFIG_IPV6_OPTIMISTIC_DAD=y
+CONFIG_INET6_AH=m
+CONFIG_INET6_ESP=m
+CONFIG_INET6_IPCOMP=m
+CONFIG_IPV6_MIP6=m
+CONFIG_IPV6_TUNNEL=m
+CONFIG_IPV6_MULTIPLE_TABLES=y
+CONFIG_CFG80211=m
+CONFIG_MAC80211=m
+CONFIG_RFKILL=y
+CONFIG_RFKILL_INPUT=y
+CONFIG_RFKILL_GPIO=y
+CONFIG_PCI=y
+CONFIG_PCIEPORTBUS=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_UBI=y
+CONFIG_OF_OVERLAY=y
+CONFIG_VIRTIO_BLK=y
+CONFIG_AD525X_DPOT=y
+CONFIG_AD525X_DPOT_I2C=y
+CONFIG_SRAM=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_DEV_SR=y
+CONFIG_ATA=y
+CONFIG_SATA_AHCI=y
+CONFIG_SATA_AHCI_PLATFORM=y
+# CONFIG_ATA_SFF is not set
+CONFIG_NETDEVICES=y
+CONFIG_VIRTIO_NET=y
+CONFIG_B53_MDIO_DRIVER=m
+CONFIG_B53_MMAP_DRIVER=m
+CONFIG_B53_SRAB_DRIVER=m
+CONFIG_B53_SERDES=m
+CONFIG_NET_DSA_BCM_SF2=m
+CONFIG_NET_VENDOR_3COM=y
+CONFIG_NET_VENDOR_ADAPTEC=y
+CONFIG_NET_VENDOR_AGERE=y
+CONFIG_NET_VENDOR_ALACRITECH=y
+CONFIG_NET_VENDOR_ALTEON=y
+# CONFIG_NET_VENDOR_AMAZON is not set
+# CONFIG_NET_VENDOR_AMD is not set
+# CONFIG_NET_VENDOR_AQUANTIA is not set
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_VENDOR_ATHEROS is not set
+# CONFIG_NET_VENDOR_AURORA is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_BROCADE is not set
+# CONFIG_NET_VENDOR_CADENCE is not set
+# CONFIG_NET_VENDOR_CAVIUM is not set
+# CONFIG_NET_VENDOR_CHELSIO is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_CISCO is not set
+# CONFIG_NET_VENDOR_CORTINA is not set
+# CONFIG_NET_VENDOR_DEC is not set
+# CONFIG_NET_VENDOR_DLINK is not set
+# CONFIG_NET_VENDOR_EMULEX is not set
+# CONFIG_NET_VENDOR_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_GOOGLE is not set
+# CONFIG_NET_VENDOR_HISILICON is not set
+# CONFIG_NET_VENDOR_HP is not set
+# CONFIG_NET_VENDOR_HUAWEI is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MELLANOX is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_MICROSEMI is not set
+# CONFIG_NET_VENDOR_MYRI is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_NETERION is not set
+# CONFIG_NET_VENDOR_NETRONOME is not set
+# CONFIG_NET_VENDOR_NI is not set
+# CONFIG_NET_VENDOR_NVIDIA is not set
+# CONFIG_NET_VENDOR_OKI is not set
+# CONFIG_NET_VENDOR_PACKET_ENGINES is not set
+# CONFIG_NET_VENDOR_QLOGIC is not set
+# CONFIG_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RDC is not set
+# CONFIG_NET_VENDOR_REALTEK is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SOLARFLARE is not set
+# CONFIG_NET_VENDOR_SILAN is not set
+# CONFIG_NET_VENDOR_SIS is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_SOCIONEXT is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SUN is not set
+# CONFIG_NET_VENDOR_SYNOPSYS is not set
+# CONFIG_NET_VENDOR_TEHUTI is not set
+# CONFIG_NET_VENDOR_TI is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+# CONFIG_NET_VENDOR_XILINX is not set
+CONFIG_INPUT_JOYDEV=y
+CONFIG_INPUT_EVDEV=y
+CONFIG_KEYBOARD_QT1070=m
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_SAMSUNG=m
+CONFIG_KEYBOARD_CROS_EC=m
+CONFIG_KEYBOARD_BCM=y
+CONFIG_MOUSE_PS2_ELANTECH=y
+CONFIG_MOUSE_CYAPA=m
+CONFIG_MOUSE_ELAN_I2C=y
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_ADC=m
+CONFIG_TOUCHSCREEN_ATMEL_MXT=m
+CONFIG_TOUCHSCREEN_ELAN=m
+CONFIG_TOUCHSCREEN_MMS114=m
+CONFIG_TOUCHSCREEN_ST1232=m
+CONFIG_TOUCHSCREEN_STMPE=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_MAX77693_HAPTIC=m
+CONFIG_INPUT_MAX8997_HAPTIC=m
+CONFIG_INPUT_AXP20X_PEK=m
+CONFIG_INPUT_ADXL34X=m
+CONFIG_INPUT_STPMIC1_ONKEY=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_8250_DW=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SERIAL_DEV_BUS=y
+CONFIG_VIRTIO_CONSOLE=y
+CONFIG_HW_RANDOM=y
+CONFIG_TCG_TPM=m
+CONFIG_TCG_TIS_I2C_INFINEON=m
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MUX=y
+CONFIG_I2C_SLAVE=y
+CONFIG_I2C_SLAVE_EEPROM=y
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_GPIOLIB=y
+CONFIG_GPIO_GENERIC_PLATFORM=y
+CONFIG_POWER_SUPPLY=y
+CONFIG_SENSORS_IIO_HWMON=y
+CONFIG_SENSORS_PWM_FAN=m
+CONFIG_THERMAL=y
+CONFIG_CPU_THERMAL=y
+CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_MFD_ACT8945A=y
+CONFIG_MFD_AS3711=y
+CONFIG_MFD_AS3722=y
+CONFIG_MFD_ATMEL_FLEXCOM=y
+CONFIG_MFD_ATMEL_HLCDC=m
+CONFIG_MFD_BCM590XX=y
+CONFIG_MFD_AXP20X_I2C=y
+CONFIG_MFD_CROS_EC=m
+CONFIG_MFD_CROS_EC_CHARDEV=m
+CONFIG_MFD_DA9063=m
+CONFIG_MFD_MAX14577=y
+CONFIG_MFD_MAX77686=y
+CONFIG_MFD_MAX77693=m
+CONFIG_MFD_MAX8907=y
+CONFIG_MFD_MAX8997=y
+CONFIG_MFD_MAX8998=y
+CONFIG_MFD_PM8XXX=y
+CONFIG_MFD_RK808=y
+CONFIG_MFD_RN5T618=y
+CONFIG_MFD_SEC_CORE=y
+CONFIG_ABX500_CORE=y
+CONFIG_MFD_STMPE=y
+CONFIG_MFD_SYSCON=y
+CONFIG_MFD_PALMAS=y
+CONFIG_MFD_TPS65090=y
+CONFIG_MFD_TPS65217=y
+CONFIG_MFD_TPS65218=y
+CONFIG_MFD_TPS6586X=y
+CONFIG_MFD_TPS65910=y
+CONFIG_TWL4030_CORE=y
+CONFIG_TWL4030_POWER=y
+CONFIG_MFD_WM8994=m
+CONFIG_MFD_STPMIC1=y
+CONFIG_MFD_STMFX=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_MEDIA_SUPPORT=m
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_MEDIA_CEC_SUPPORT=y
+CONFIG_MEDIA_CONTROLLER=y
+CONFIG_VIDEO_V4L2_SUBDEV_API=y
+CONFIG_MEDIA_USB_SUPPORT=y
+CONFIG_USB_VIDEO_CLASS=m
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_V4L_TEST_DRIVERS=y
+CONFIG_VIDEO_VIVID=m
+CONFIG_CEC_PLATFORM_DRIVERS=y
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_DRM=y
+CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_DRM_PANEL_ORISETECH_OTM8009A=m
+CONFIG_DRM_PANEL_RAYDIUM_RM68200=m
+CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03=m
+CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
+CONFIG_DRM_DUMB_VGA_DAC=m
+CONFIG_DRM_NXP_PTN3460=m
+CONFIG_DRM_PARADE_PS8622=m
+CONFIG_DRM_SII902X=m
+CONFIG_DRM_SII9234=m
+CONFIG_DRM_TOSHIBA_TC358764=m
+CONFIG_DRM_I2C_ADV7511=m
+CONFIG_DRM_I2C_ADV7511_AUDIO=y
+CONFIG_DRM_PANFROST=m
+CONFIG_DRM_LEGACY=y
+CONFIG_FB_MODE_HELPERS=y
+CONFIG_FB_EFI=y
+CONFIG_FB_SIMPLE=y
+CONFIG_LCD_PLATFORM=m
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_PWM=y
+CONFIG_BACKLIGHT_GPIO=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
+CONFIG_SOUND=m
+CONFIG_SND=m
+CONFIG_SND_DYNAMIC_MINORS=y
+CONFIG_SND_USB_AUDIO=m
+CONFIG_SND_SOC=m
+CONFIG_SND_SOC_FSL_SAI=m
+CONFIG_SND_SIMPLE_CARD=m
+CONFIG_USB=y
+CONFIG_USB_OTG=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_UAS=y
+CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_HAPS is not set
+# CONFIG_USB_DWC3_OF_SIMPLE is not set
+CONFIG_NOP_USB_XCEIV=y
+CONFIG_USB_GPIO_VBUS=y
+CONFIG_USB_ULPI=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_SNP_UDC_PLAT=y
+CONFIG_USB_BDC_UDC=y
+CONFIG_USB_CONFIGFS=m
+CONFIG_USB_CONFIGFS_SERIAL=y
+CONFIG_USB_CONFIGFS_ACM=y
+CONFIG_USB_CONFIGFS_OBEX=y
+CONFIG_USB_CONFIGFS_NCM=y
+CONFIG_USB_CONFIGFS_ECM=y
+CONFIG_USB_CONFIGFS_ECM_SUBSET=y
+CONFIG_USB_CONFIGFS_RNDIS=y
+CONFIG_USB_CONFIGFS_EEM=y
+CONFIG_USB_CONFIGFS_MASS_STORAGE=y
+CONFIG_USB_CONFIGFS_F_LB_SS=y
+CONFIG_USB_CONFIGFS_F_FS=y
+CONFIG_USB_CONFIGFS_F_UAC1=y
+CONFIG_USB_CONFIGFS_F_UAC1_LEGACY=y
+CONFIG_USB_CONFIGFS_F_UAC2=y
+CONFIG_USB_CONFIGFS_F_MIDI=y
+CONFIG_USB_CONFIGFS_F_HID=y
+CONFIG_USB_CONFIGFS_F_UVC=y
+CONFIG_USB_CONFIGFS_F_PRINTER=y
+CONFIG_USB_ETH=m
+CONFIG_USB_ROLE_SWITCH=y
+CONFIG_USB_ULPI_BUS=y
+CONFIG_MMC=y
+CONFIG_MMC_BLOCK_MINORS=16
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_CQHCI=y
+CONFIG_EDAC=y
+CONFIG_RTC_CLASS=y
+CONFIG_DMADEVICES=y
+CONFIG_SW_SYNC=y
+CONFIG_UDMABUF=y
+CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_MMIO=y
+CONFIG_STAGING=y
+CONFIG_CROS_EC_I2C=m
+CONFIG_REMOTEPROC=m
+CONFIG_RPMSG_VIRTIO=m
+CONFIG_MEMORY=y
+CONFIG_IIO=y
+CONFIG_IIO_BUFFER_HW_CONSUMER=m
+CONFIG_IIO_KFIFO_BUF=y
+CONFIG_IIO_SW_TRIGGER=y
+CONFIG_IIO_CROS_EC_SENSORS_CORE=m
+CONFIG_IIO_CROS_EC_SENSORS=m
+CONFIG_IIO_HRTIMER_TRIGGER=y
+CONFIG_PWM=y
+CONFIG_RESET_CONTROLLER=y
+CONFIG_GENERIC_PHY=y
+CONFIG_EXT4_FS=y
+CONFIG_AUTOFS4_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_NTFS_FS=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_UBIFS_FS=y
+CONFIG_SQUASHFS=y
+CONFIG_SQUASHFS_LZO=y
+CONFIG_SQUASHFS_XZ=y
+CONFIG_PSTORE=y
+CONFIG_PSTORE_CONSOLE=y
+CONFIG_PSTORE_PMSG=y
+CONFIG_PSTORE_RAM=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_CRYPTO_USER=m
+CONFIG_CRYPTO_SHA512=m
+CONFIG_CRYPTO_USER_API_HASH=m
+CONFIG_CRYPTO_USER_API_SKCIPHER=m
+CONFIG_CRYPTO_USER_API_RNG=m
+CONFIG_CRYPTO_USER_API_AEAD=m
+CONFIG_DMA_CMA=y
+CONFIG_CMA_SIZE_MBYTES=64
+CONFIG_PRINTK_TIME=y
+CONFIG_MAGIC_SYSRQ=y
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 2/3] drm/rockchip: Add vop_format_get_bpp to get format bpp
From: Sandy Huang @ 2019-09-25  8:06 UTC (permalink / raw)
  To: dri-devel, Sandy Huang, Heiko Stübner, David Airlie,
	Daniel Vetter
  Cc: linux-rockchip, Ayan.Halder, linux-kernel, linux-arm-kernel
In-Reply-To: <1569398801-92201-1-git-send-email-hjc@rock-chips.com>

For 10bit yuv format, we need to get format bpp each plane, so we
Add vop_format_get_bpp() to instead of format->cpp[];

Signed-off-by: Sandy Huang <hjc@rock-chips.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2f821c5..ce5b45d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -249,6 +249,25 @@ static bool has_rb_swapped(uint32_t format)
 	}
 }
 
+static int vop_format_get_bpp(u32 format, u8 plane)
+{
+	const struct drm_format_info *info;
+
+	info = drm_format_info(format);
+	if (!info || plane >= info->num_planes)
+		return 0;
+
+	if (info->cpp[0] == 0) {
+		/* only support DRM_FORMAT_NVxx_10 now */
+		if (plane == 0)
+			return 10;
+		else
+			return 20;
+	}
+
+	return info->cpp[plane] * 8;
+}
+
 static enum vop_data_format vop_convert_format(uint32_t format)
 {
 	switch (format) {
@@ -832,7 +851,8 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
 	dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
 	dsp_st = dsp_sty << 16 | (dsp_stx & 0xffff);
 
-	offset = (src->x1 >> 16) * fb->format->cpp[0];
+	offset = (src->x1 >> 16) *
+			vop_format_get_bpp(fb->format->format, 0) / 8;
 	offset += (src->y1 >> 16) * fb->pitches[0];
 	dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
 
@@ -859,12 +879,12 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
 	if (is_yuv) {
 		int hsub = fb->format->hsub;
 		int vsub = fb->format->vsub;
-		int bpp = fb->format->cpp[1];
+		int bpp = vop_format_get_bpp(fb->format->format, 1);
 
 		uv_obj = fb->obj[1];
 		rk_uv_obj = to_rockchip_obj(uv_obj);
 
-		offset = (src->x1 >> 16) * bpp / hsub;
+		offset = (src->x1 >> 16) * bpp / 8 / hsub;
 		offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
 
 		dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
-- 
2.7.4




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 3/3] drm/rockchip: Add support 10bit yuv format
From: Sandy Huang @ 2019-09-25  8:06 UTC (permalink / raw)
  To: dri-devel, Sandy Huang, Heiko Stübner, David Airlie,
	Daniel Vetter
  Cc: linux-rockchip, Ayan.Halder, linux-kernel, linux-arm-kernel
In-Reply-To: <1569398801-92201-1-git-send-email-hjc@rock-chips.com>

Add support 10bit yuv format display for rockchip some socs,
include:
    RK3288/RK3228/RK3328/RK3368/RK3399

Signed-off-by: Sandy Huang <hjc@rock-chips.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 16 ++++++++++++++++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  2 ++
 3 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ce5b45d..9cb9fff 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -249,6 +249,21 @@ static bool has_rb_swapped(uint32_t format)
 	}
 }
 
+static bool is_yuv_10bit(uint32_t format)
+{
+	switch (format) {
+	case DRM_FORMAT_NV12_10:
+	case DRM_FORMAT_NV21_10:
+	case DRM_FORMAT_NV16_10:
+	case DRM_FORMAT_NV61_10:
+	case DRM_FORMAT_NV24_10:
+	case DRM_FORMAT_NV42_10:
+		return true;
+	default:
+		return false;
+	}
+}
+
 static int vop_format_get_bpp(u32 format, u8 plane)
 {
 	const struct drm_format_info *info;
@@ -890,6 +905,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
 		dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
 		VOP_WIN_SET(vop, win, uv_vir, DIV_ROUND_UP(fb->pitches[1], 4));
 		VOP_WIN_SET(vop, win, uv_mst, dma_addr);
+		VOP_WIN_SET(vop, win, fmt_10, is_yuv_10bit(fb->format->format));
 
 		for (i = 0; i < NUM_YUV2YUV_COEFFICIENTS; i++) {
 			VOP_WIN_YUV2YUV_COEFFICIENT_SET(vop,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 2149a889..adc2b0b5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -133,6 +133,7 @@ struct vop_win_phy {
 	struct vop_reg gate;
 	struct vop_reg format;
 	struct vop_reg rb_swap;
+	struct vop_reg fmt_10;
 	struct vop_reg act_info;
 	struct vop_reg dsp_info;
 	struct vop_reg dsp_st;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index d1494be..732e535 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -544,6 +544,7 @@ static const struct vop_win_phy rk3288_win01_data = {
 	.nformats = ARRAY_SIZE(formats_win_full),
 	.enable = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 0),
 	.format = VOP_REG(RK3288_WIN0_CTRL0, 0x7, 1),
+	.fmt_10 = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 4),
 	.rb_swap = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 12),
 	.act_info = VOP_REG(RK3288_WIN0_ACT_INFO, 0x1fff1fff, 0),
 	.dsp_info = VOP_REG(RK3288_WIN0_DSP_INFO, 0x0fff0fff, 0),
@@ -674,6 +675,7 @@ static const struct vop_win_phy rk3368_win01_data = {
 	.nformats = ARRAY_SIZE(formats_win_full),
 	.enable = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 0),
 	.format = VOP_REG(RK3368_WIN0_CTRL0, 0x7, 1),
+	.fmt_10 = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 4),
 	.rb_swap = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 12),
 	.x_mir_en = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 21),
 	.y_mir_en = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 22),
-- 
2.7.4




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [RFC PATCH 01/12] linux-headers: import arm_sdei.h
From: Guoheyi @ 2019-09-25  8:12 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Mark Rutland, Peter Maydell, Marc Zyngier, Cornelia Huck,
	qemu-devel, Dave Martin, qemu-arm, James Morse, Paolo Bonzini,
	wanghaibin.wang, kvmarm, linux-arm-kernel
In-Reply-To: <20190924113640-mutt-send-email-mst@kernel.org>



On 2019/9/24 23:39, Michael S. Tsirkin wrote:
> On Tue, Sep 24, 2019 at 11:21:40PM +0800, Heyi Guo wrote:
>> Import Linux header file include/uapi/linux/arm_sdei.h from kernel
>> v5.3 release.
>>
>> This is to prepare for qemu SDEI emulation.
>>
>> Signed-off-by: Heyi Guo <guoheyi@huawei.com>
>> Cc: Peter Maydell <peter.maydell@linaro.org>
>> Cc: Dave Martin <Dave.Martin@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: James Morse <james.morse@arm.com>
>> Cc: "Michael S. Tsirkin" <mst@redhat.com>
>> Cc: Cornelia Huck <cohuck@redhat.com>
>> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Some issues with this.  First linux-headers is for linux as a host.
> This is for linux as a guest, so belongs in include/standard-headers.
>
> Second, please add to scripts/update-linux-headers.sh in a 1st patch,
> then add the file in the second patch.

Thanks; now I understand the differences. I'll do that in next version.

HG

>
>
>
>> ---
>>   linux-headers/linux/arm_sdei.h | 73 ++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 73 insertions(+)
>>   create mode 100644 linux-headers/linux/arm_sdei.h
>>
>> diff --git a/linux-headers/linux/arm_sdei.h b/linux-headers/linux/arm_sdei.h
>> new file mode 100644
>> index 0000000..af0630b
>> --- /dev/null
>> +++ b/linux-headers/linux/arm_sdei.h
>> @@ -0,0 +1,73 @@
>> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>> +/* Copyright (C) 2017 Arm Ltd. */
>> +#ifndef _UAPI_LINUX_ARM_SDEI_H
>> +#define _UAPI_LINUX_ARM_SDEI_H
>> +
>> +#define SDEI_1_0_FN_BASE			0xC4000020
>> +#define SDEI_1_0_MASK				0xFFFFFFE0
>> +#define SDEI_1_0_FN(n)				(SDEI_1_0_FN_BASE + (n))
>> +
>> +#define SDEI_1_0_FN_SDEI_VERSION			SDEI_1_0_FN(0x00)
>> +#define SDEI_1_0_FN_SDEI_EVENT_REGISTER			SDEI_1_0_FN(0x01)
>> +#define SDEI_1_0_FN_SDEI_EVENT_ENABLE			SDEI_1_0_FN(0x02)
>> +#define SDEI_1_0_FN_SDEI_EVENT_DISABLE			SDEI_1_0_FN(0x03)
>> +#define SDEI_1_0_FN_SDEI_EVENT_CONTEXT			SDEI_1_0_FN(0x04)
>> +#define SDEI_1_0_FN_SDEI_EVENT_COMPLETE			SDEI_1_0_FN(0x05)
>> +#define SDEI_1_0_FN_SDEI_EVENT_COMPLETE_AND_RESUME	SDEI_1_0_FN(0x06)
>> +#define SDEI_1_0_FN_SDEI_EVENT_UNREGISTER		SDEI_1_0_FN(0x07)
>> +#define SDEI_1_0_FN_SDEI_EVENT_STATUS			SDEI_1_0_FN(0x08)
>> +#define SDEI_1_0_FN_SDEI_EVENT_GET_INFO			SDEI_1_0_FN(0x09)
>> +#define SDEI_1_0_FN_SDEI_EVENT_ROUTING_SET		SDEI_1_0_FN(0x0A)
>> +#define SDEI_1_0_FN_SDEI_PE_MASK			SDEI_1_0_FN(0x0B)
>> +#define SDEI_1_0_FN_SDEI_PE_UNMASK			SDEI_1_0_FN(0x0C)
>> +#define SDEI_1_0_FN_SDEI_INTERRUPT_BIND			SDEI_1_0_FN(0x0D)
>> +#define SDEI_1_0_FN_SDEI_INTERRUPT_RELEASE		SDEI_1_0_FN(0x0E)
>> +#define SDEI_1_0_FN_SDEI_PRIVATE_RESET			SDEI_1_0_FN(0x11)
>> +#define SDEI_1_0_FN_SDEI_SHARED_RESET			SDEI_1_0_FN(0x12)
>> +
>> +#define SDEI_VERSION_MAJOR_SHIFT			48
>> +#define SDEI_VERSION_MAJOR_MASK				0x7fff
>> +#define SDEI_VERSION_MINOR_SHIFT			32
>> +#define SDEI_VERSION_MINOR_MASK				0xffff
>> +#define SDEI_VERSION_VENDOR_SHIFT			0
>> +#define SDEI_VERSION_VENDOR_MASK			0xffffffff
>> +
>> +#define SDEI_VERSION_MAJOR(x)	(x>>SDEI_VERSION_MAJOR_SHIFT & SDEI_VERSION_MAJOR_MASK)
>> +#define SDEI_VERSION_MINOR(x)	(x>>SDEI_VERSION_MINOR_SHIFT & SDEI_VERSION_MINOR_MASK)
>> +#define SDEI_VERSION_VENDOR(x)	(x>>SDEI_VERSION_VENDOR_SHIFT & SDEI_VERSION_VENDOR_MASK)
>> +
>> +/* SDEI return values */
>> +#define SDEI_SUCCESS		0
>> +#define SDEI_NOT_SUPPORTED	-1
>> +#define SDEI_INVALID_PARAMETERS	-2
>> +#define SDEI_DENIED		-3
>> +#define SDEI_PENDING		-5
>> +#define SDEI_OUT_OF_RESOURCE	-10
>> +
>> +/* EVENT_REGISTER flags */
>> +#define SDEI_EVENT_REGISTER_RM_ANY	0
>> +#define SDEI_EVENT_REGISTER_RM_PE	1
>> +
>> +/* EVENT_STATUS return value bits */
>> +#define SDEI_EVENT_STATUS_RUNNING	2
>> +#define SDEI_EVENT_STATUS_ENABLED	1
>> +#define SDEI_EVENT_STATUS_REGISTERED	0
>> +
>> +/* EVENT_COMPLETE status values */
>> +#define SDEI_EV_HANDLED	0
>> +#define SDEI_EV_FAILED	1
>> +
>> +/* GET_INFO values */
>> +#define SDEI_EVENT_INFO_EV_TYPE			0
>> +#define SDEI_EVENT_INFO_EV_SIGNALED		1
>> +#define SDEI_EVENT_INFO_EV_PRIORITY		2
>> +#define SDEI_EVENT_INFO_EV_ROUTING_MODE		3
>> +#define SDEI_EVENT_INFO_EV_ROUTING_AFF		4
>> +
>> +/* and their results */
>> +#define SDEI_EVENT_TYPE_PRIVATE			0
>> +#define SDEI_EVENT_TYPE_SHARED			1
>> +#define SDEI_EVENT_PRIORITY_NORMAL		0
>> +#define SDEI_EVENT_PRIORITY_CRITICAL		1
>> +
>> +#endif /* _UAPI_LINUX_ARM_SDEI_H */
>> -- 
>> 1.8.3.1
> .
>



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 01/11] PCI: aardvark: Use pci_parse_request_of_pci_ranges()
From: Thomas Petazzoni @ 2019-09-25  8:59 UTC (permalink / raw)
  To: Rob Herring
  Cc: Bjorn Helgaas, linux-pci, Nadav Haklai, Lorenzo Pieralisi,
	linux-arm-kernel
In-Reply-To: <20190924214630.12817-2-robh@kernel.org>

On Tue, 24 Sep 2019 16:46:20 -0500
Rob Herring <robh@kernel.org> wrote:

> Convert aardvark to use the common pci_parse_request_of_pci_ranges().
> 
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
>  drivers/pci/controller/pci-aardvark.c | 58 ++-------------------------
>  1 file changed, 4 insertions(+), 54 deletions(-)

Tested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(on Armada 3720-DB, with a E1000E NIC)

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 06/11] PCI: of: Add inbound resource parsing to helpers
From: Thomas Petazzoni @ 2019-09-25  9:00 UTC (permalink / raw)
  To: Rob Herring
  Cc: Heiko Stuebner, Karthikeyan Mitran, linux-pci, Linus Walleij,
	Ryder Lee, Nadav Haklai, Toan Le, Will Deacon, Lorenzo Pieralisi,
	Michal Simek, linux-rockchip, bcm-kernel-feedback-list, Shawn Lin,
	Ray Jui, Hou Zhiqiang, Simon Horman, linux-mediatek,
	Bjorn Helgaas, linux-arm-kernel, Scott Branden, Jingoo Han, rfi,
	linux-renesas-soc, Tom Joseph, Gustavo Pimentel, Ley Foon Tan
In-Reply-To: <20190924214630.12817-7-robh@kernel.org>

On Tue, 24 Sep 2019 16:46:25 -0500
Rob Herring <robh@kernel.org> wrote:

> Extend devm_of_pci_get_host_bridge_resources() and
> pci_parse_request_of_pci_ranges() helpers to also parse the inbound
> addresses from DT 'dma-ranges' and populate a resource list with the
> translated addresses. This will help ensure 'dma-ranges' is always
> parsed in a consistent way.
> 
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Toan Le <toan@os.amperecomputing.com>
> Cc: Ley Foon Tan <lftan@altera.com>
> Cc: Tom Joseph <tjoseph@cadence.com>
> Cc: Ray Jui <rjui@broadcom.com>
> Cc: Scott Branden <sbranden@broadcom.com>
> Cc: bcm-kernel-feedback-list@broadcom.com
> Cc: Ryder Lee <ryder.lee@mediatek.com>
> Cc: Karthikeyan Mitran <m.karthikeyan@mobiveil.co.in>
> Cc: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: Shawn Lin <shawn.lin@rock-chips.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: rfi@lists.rocketboards.org
> Cc: linux-mediatek@lists.infradead.org
> Cc: linux-renesas-soc@vger.kernel.org
> Cc: linux-rockchip@lists.infradead.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
>  .../pci/controller/dwc/pcie-designware-host.c |  3 +-
>  drivers/pci/controller/pci-aardvark.c         |  2 +-
>  drivers/pci/controller/pci-ftpci100.c         |  3 +-
>  drivers/pci/controller/pci-host-common.c      |  2 +-
>  drivers/pci/controller/pci-v3-semi.c          |  2 +-
>  drivers/pci/controller/pci-versatile.c        |  2 +-
>  drivers/pci/controller/pci-xgene.c            |  1 +
>  drivers/pci/controller/pcie-altera.c          |  2 +-
>  drivers/pci/controller/pcie-cadence-host.c    |  2 +-
>  drivers/pci/controller/pcie-iproc-platform.c  |  1 +
>  drivers/pci/controller/pcie-mediatek.c        |  2 +-
>  drivers/pci/controller/pcie-mobiveil.c        |  4 +-
>  drivers/pci/controller/pcie-rcar.c            |  3 +-
>  drivers/pci/controller/pcie-rockchip-host.c   |  3 +-
>  drivers/pci/controller/pcie-xilinx-nwl.c      |  2 +-
>  drivers/pci/controller/pcie-xilinx.c          |  2 +-
>  drivers/pci/of.c                              | 44 ++++++++++++++++++-
>  drivers/pci/pci.h                             |  8 +++-
>  include/linux/pci.h                           |  2 +
>  19 files changed, 72 insertions(+), 18 deletions(-)

for the AArdvark bits:

Tested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
(on Armada 3720-DB, with a E1000E NIC)

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 01/11] PCI: aardvark: Use pci_parse_request_of_pci_ranges()
From: Andrew Murray @ 2019-09-25  9:04 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: Rob Herring, Lorenzo Pieralisi, linux-pci, Nadav Haklai,
	Bjorn Helgaas, linux-arm-kernel
In-Reply-To: <20190925105944.30fe64cd@windsurf>

On Wed, Sep 25, 2019 at 10:59:44AM +0200, Thomas Petazzoni wrote:
> On Tue, 24 Sep 2019 16:46:20 -0500
> Rob Herring <robh@kernel.org> wrote:
> 
> > Convert aardvark to use the common pci_parse_request_of_pci_ranges().
> > 
> > Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> >  drivers/pci/controller/pci-aardvark.c | 58 ++-------------------------
> >  1 file changed, 4 insertions(+), 54 deletions(-)
> 
> Tested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> (on Armada 3720-DB, with a E1000E NIC)

Reviewed-by: Andrew Murray <andrew.murray@arm.com>

> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH] interconnect: Replace of_icc_get() with icc_get() and reduce DT binding
From: Maxime Ripard @ 2019-09-25  9:15 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: devicetree, linux-pm, linux-arm-msm, David Dai, linux-kernel,
	Evan Green, Bjorn Andersson, Rob Herring, Georgi Djakov,
	linux-arm-kernel
In-Reply-To: <20190925054133.206992-1-swboyd@chromium.org>


[-- Attachment #1.1: Type: text/plain, Size: 1541 bytes --]

Hi Stephen,

On Tue, Sep 24, 2019 at 10:41:33PM -0700, Stephen Boyd wrote:
> The DT binding could also be simplified somewhat. Currently a path needs
> to be specified in DT for each and every use case that is possible for a
> device to want. Typically the path is to memory, which looks to be
> reserved for in the binding with the "dma-mem" named path, but sometimes
> the path is from a device to the CPU or more generically from a device
> to another device which could be a CPU, cache, DMA master, or another
> device if some sort of DMA to DMA scenario is happening. Let's remove
> the pair part of the binding so that we just list out a device's
> possible endpoints on the bus or busses that it's connected to.
>
> If the kernel wants to figure out what the path is to memory or the CPU
> or a cache or something else it should be able to do that by finding the
> node for the "destination" endpoint, extracting that node's
> "interconnects" property, and deriving the path in software. For
> example, we shouldn't need to write out each use case path by path in DT
> for each endpoint node that wants to set a bandwidth to memory. We
> should just be able to indicate what endpoint(s) a device sits on based
> on the interconnect provider in the system and then walk the various
> interconnects to find the path from that source endpoint to the
> destination endpoint.

The dma-mem name is used by the OF core to adjust the mapping of the
devices as well. So, any solution needs to be generic (or provide a
generic helper).

Maxime

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: ARM core blob list
From: Neil Armstrong @ 2019-09-25  9:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <7c52fab5-825a-b019-ec46-6fb731336cfe@ehayq.am>

Hi,

On 20/09/2019 12:15, Sergey Brutyan wrote:
> Dear all we are company of hard/soft design and integration mostly based
> on ARM cores.
> We are currently working on Libre Linux development for ARM based SBC.
> 
> And ready to put professional effort for having complete blob-free Linux
> kernel, as we have done research there is most problem with bootloaders
> and Mali or PowerVR GPU units in SoC.
> 
> We are looking forward to cooperate and  now have several need of
> information.
> 
> Can you send us list for blob drivers for this SoC:
> 
>     Allwinner A20
>     Allwinner R40
>     Broadcom BCM2837
>     Realtek RTD1395
>     MediaTek MT7623N
> 
> 
> And also please offer us which is the best SoC for blob-free linux
> development.

off topic, but I can answer for the Amlogic S905/S905X/S905D/S912/S905X2/S905D2/S922X/A113D/S905X3/S905D3 :

- S905/S905X/S905D/S912
U-Boot support is blob free, full upstream
Linux support is fully upstream
SCPI firmware for DVFS, loaded by TF-A to SCP Co-Coprocessor
PSCI firmware for System Management, but BL31 has been reverse engineered and pushed to official TF-A repos, only BL2, BL30 and BL301 are still closed source
GPU can use the FOSS Lima (Panfrost for S912) driver
HW Video Decoder needs a firmware to be loaded

- S905X2/S905D2/S922X/A113D/S905X3/S905D3
U-Boot support is blob free, full upstream
Linux support is fully upstream
DVFS is blob-free, handled by Linux
PSCI firmware for System Management, but BL31 is being reverse engineered and pushed to official TF-A repos, only BL2, DDR setup firmwares, BL30 and BL301 are still closed source
GPU is BLOB Only
HW Video Decoder needs a firmware to be loaded

Neil

> 
> Best regards. Sergey.
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] drm/rockchip: Add AFBC support
From: Ayan Halder @ 2019-09-25  9:28 UTC (permalink / raw)
  To: Andrzej Pietrasiewicz
  Cc: nd, Tomeu Vizoso, Neil Armstrong, David Airlie, Sean Paul,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, Maxime Ripard,
	kernel@collabora.com, Ezequiel Garcia,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <332335a5-dc7f-2cce-601f-f73e9243dee5@collabora.com>

On Mon, Sep 23, 2019 at 05:34:14PM +0200, Andrzej Pietrasiewicz wrote:
> Dear All,
> 
> As a result of my mistake I've sent this patch with an incorrect SOB chain.
> Please kindly disregard this patch.
> 
> @Neil: thank you for your time you spent reviewing it and answering and I'm
> sorry it's to no effect.
> @Ezequiel, @Tomeu: I apologize to you. My mistake.
> 
> Regards,
> 
> Andrzej Pietrasiewicz
> 
> 
> W dniu 23.09.2019 o 15:53, Neil Armstrong pisze:
> >On 23/09/2019 14:20, Andrzej Pietrasiewicz wrote:
> >>From: Ezequiel Garcia <ezequiel@collabora.com>
> >>
> >>AFBC is a proprietary lossless image compression protocol and format.
> >>It helps reduce memory bandwidth of the graphics pipeline operations.
> >>This, in turn, improves power efficiency.
> >>
> >>Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> >>[locking improvements]
> >>Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >>[squashing the above, commit message and Rockchip AFBC modifier]
> >>Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> >>---
> >>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 27 ++++++
> >>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 94 ++++++++++++++++++++-
> >>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 +++
> >>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 18 ++++
> >>  include/uapi/drm/drm_fourcc.h               |  3 +
> >>  5 files changed, 151 insertions(+), 3 deletions(-)
> >>
> >
> >[...]
> >
> >>diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >>index 3feeaa3f987a..ba6caf06c824 100644
> >>--- a/include/uapi/drm/drm_fourcc.h
> >>+++ b/include/uapi/drm/drm_fourcc.h
> >>@@ -742,6 +742,9 @@ extern "C" {
> >>   */
> >>  #define AFBC_FORMAT_MOD_BCH     (1ULL << 11)
> >>+#define AFBC_FORMAT_MOD_ROCKCHIP \
> >>+	(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE)
> >
> >This define looks useless, what's Rockchip specific here ?
> >
Please reuse the existing AFBC modifiers.

Have a look at malidp_format_modifiers[] in which we have defined
the modifiers(for our driver) we are using.

In your case, it will be
DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16|AFBC_FORMAT_MOD_SPARSE)

> >Neil
> >
> >>+
> >>  /*
> >>   * Allwinner tiled modifier
> >>   *
> >>
> >
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] PCI: aardvark: Don't rely on jiffies while holding spinlock
From: Thomas Petazzoni @ 2019-09-25  9:33 UTC (permalink / raw)
  To: Remi Pommarel
  Cc: Bjorn Helgaas, linux-pci, Lorenzo Pieralisi, linux-kernel,
	linux-arm-kernel
In-Reply-To: <20190901142303.27815-1-repk@triplefau.lt>

Hello Remi,

Thanks for the patch, I have a few comments/questions below.

On Sun,  1 Sep 2019 16:23:03 +0200
Remi Pommarel <repk@triplefau.lt> wrote:

> diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
> index fc0fe4d4de49..1fa6d04ad7aa 100644
> --- a/drivers/pci/controller/pci-aardvark.c
> +++ b/drivers/pci/controller/pci-aardvark.c
> @@ -175,7 +175,8 @@
>  	(PCIE_CONF_BUS(bus) | PCIE_CONF_DEV(PCI_SLOT(devfn))	| \
>  	 PCIE_CONF_FUNC(PCI_FUNC(devfn)) | PCIE_CONF_REG(where))
>  
> -#define PIO_TIMEOUT_MS			1
> +#define PIO_RETRY_CNT			10
> +#define PIO_RETRY_DELAY			100 /* 100 us*/
>  
>  #define LINK_WAIT_MAX_RETRIES		10
>  #define LINK_WAIT_USLEEP_MIN		90000
> @@ -383,17 +384,16 @@ static void advk_pcie_check_pio_status(struct advk_pcie *pcie)
>  static int advk_pcie_wait_pio(struct advk_pcie *pcie)
>  {
>  	struct device *dev = &pcie->pdev->dev;
> -	unsigned long timeout;
> +	size_t i;

Is it common to use a size_t for a loop counter ?

>  
> -	timeout = jiffies + msecs_to_jiffies(PIO_TIMEOUT_MS);
> -
> -	while (time_before(jiffies, timeout)) {
> +	for (i = 0; i < PIO_RETRY_CNT; ++i) {

I find it more common to use post-increment for loop counters rather
than pre-increment, but that's a really nitpick and I don't care much.

>  		u32 start, isr;
>  
>  		start = advk_readl(pcie, PIO_START);
>  		isr = advk_readl(pcie, PIO_ISR);
>  		if (!start && isr)
>  			return 0;
> +		udelay(PIO_RETRY_DELAY);

But the bigger issue is that this change causes a 100us delay at
*every* single PIO read or write operation.

Indeed, at the first iteration of the loop, the PIO operation has not
completed, so you will always hit the udelay(100) a first time, and
it's only at the second iteration of the loop that the PIO operation
has completed (for successful PIO operations of course, which don't hit
the timeout).

I took a measurement around wait_pio() with sched_clock before and
after the patch. Before the patch, I have measurements like this (in
nanoseconds):

[    1.562801] time = 6000
[    1.565310] time = 6000
[    1.567809] time = 6080
[    1.570327] time = 6080
[    1.572836] time = 6080
[    1.575339] time = 6080
[    1.577858] time = 2720
[    1.580366] time = 2720
[    1.582862] time = 6000
[    1.585377] time = 2720
[    1.587890] time = 2720
[    1.590393] time = 2720

So it takes a few microseconds for each PIO operation.

With your patch applied:

[    2.267291] time = 101680
[    2.270002] time = 100880
[    2.272852] time = 100800
[    2.275573] time = 100880
[    2.278285] time = 100800
[    2.281005] time = 100880
[    2.283722] time = 100800
[    2.286444] time = 100880
[    2.289264] time = 100880
[    2.291981] time = 100800
[    2.294690] time = 100800
[    2.297405] time = 100800

We're jumping to 100us for every PIO read/write operation. To be
honest, I don't know if this is very important, there are not that many
PIO operations, and they are not used in any performance hot path. But
I thought it was worth pointing out the additional delay caused by this
implementation change.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] drm/rockchip: Add AFBC support
From: Ayan Halder @ 2019-09-25  9:35 UTC (permalink / raw)
  To: Andrzej Pietrasiewicz
  Cc: nd, Tomeu Vizoso, David Airlie, Ezequiel Garcia,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, Maxime Ripard,
	kernel@collabora.com, Sean Paul,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190923122014.18229-1-andrzej.p@collabora.com>

On Mon, Sep 23, 2019 at 02:20:13PM +0200, Andrzej Pietrasiewicz wrote:
> From: Ezequiel Garcia <ezequiel@collabora.com>
> 
> AFBC is a proprietary lossless image compression protocol and format.
> It helps reduce memory bandwidth of the graphics pipeline operations.
> This, in turn, improves power efficiency.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> [locking improvements]
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> [squashing the above, commit message and Rockchip AFBC modifier]
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 27 ++++++
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 94 ++++++++++++++++++++-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 +++
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 18 ++++
>  include/uapi/drm/drm_fourcc.h               |  3 +
>  5 files changed, 151 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 64ca87cf6d50..5178939a9c29 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -24,6 +24,27 @@ static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
>  	.dirty	       = drm_atomic_helper_dirtyfb,
>  };
>  
> +static int
> +rockchip_verify_afbc_mod(struct drm_device *dev,
> +			 const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> +	if (mode_cmd->modifier[0] &
> +	    ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP)) {
> +		DRM_DEV_ERROR(dev->dev,
> +			      "Unsupported format modifier 0x%llx\n",
> +			      mode_cmd->modifier[0]);
> +		return -EINVAL;
> +	}
> +
> +	if (mode_cmd->width > 2560) {
> +		DRM_DEV_ERROR(dev->dev,
> +			      "Unsupported width %d\n", mode_cmd->width);
> +		return -EINVAL;
> +	}
> +
I think you are missing one additional check here.
framebuffer width and height should be aligned to 16 pixels as you are
using AFBC_FORMAT_MOD_BLOCK_SIZE_16x16.
Please have a look at malidp_verify_afbc_framebuffer_caps()

> +	return 0;
> +}
> +
>  static struct drm_framebuffer *
>  rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cmd,
>  		  struct drm_gem_object **obj, unsigned int num_planes)
> @@ -32,6 +53,12 @@ rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cm
>  	int ret;
>  	int i;
>  
> +	if (mode_cmd->modifier[0]) {
> +		ret = rockchip_verify_afbc_mod(dev, mode_cmd);
> +		if (ret)
> +			return ERR_PTR(ret);
> +	}
> +
>  	fb = kzalloc(sizeof(*fb), GFP_KERNEL);
>  	if (!fb)
>  		return ERR_PTR(-ENOMEM);
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 21b68eea46cc..50bf214d21da 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -46,6 +46,13 @@
>  		vop_reg_set(vop, &win->phy->scl->ext->name, \
>  			    win->base, ~0, v, #name)
>  
> +#define VOP_AFBC_SET(x, name, v) \
> +	do { \
> +		if (vop->data->afbc) \
> +			vop_reg_set(vop, &vop->data->afbc->name, \
> +				0, ~0, v, #name); \
> +	} while (0)
> +
>  #define VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, name, v) \
>  	do { \
>  		if (win_yuv2yuv && win_yuv2yuv->name.mask) \
> @@ -123,6 +130,8 @@ struct vop {
>  	struct drm_device *drm_dev;
>  	bool is_enabled;
>  
> +	struct vop_win *afbc_win;
> +
>  	struct completion dsp_hold_completion;
>  
>  	/* protected by dev->event_lock */
> @@ -245,6 +254,30 @@ static bool has_rb_swapped(uint32_t format)
>  	}
>  }
>  
> +#define AFBC_FMT_RGB565        0x0
> +#define AFBC_FMT_U8U8U8U8      0x5
> +#define AFBC_FMT_U8U8U8        0x4
> +
> +static int vop_convert_afbc_format(uint32_t format)
> +{
> +	switch (format) {
> +	case DRM_FORMAT_XRGB8888:
> +	case DRM_FORMAT_ARGB8888:
> +	case DRM_FORMAT_XBGR8888:
> +	case DRM_FORMAT_ABGR8888:
> +		return AFBC_FMT_U8U8U8U8;
> +	case DRM_FORMAT_RGB888:
> +	case DRM_FORMAT_BGR888:
> +		return AFBC_FMT_U8U8U8;
> +	case DRM_FORMAT_RGB565:
> +	case DRM_FORMAT_BGR565:
> +		return AFBC_FMT_RGB565;
> +	default:
> +		DRM_ERROR("unsupported afbc format[%08x]\n", format);
> +		return -EINVAL;
> +	}
> +}
> +
>  static enum vop_data_format vop_convert_format(uint32_t format)
>  {
>  	switch (format) {
> @@ -587,10 +620,16 @@ static int vop_enable(struct drm_crtc *crtc)
>  
>  		vop_win_disable(vop, win);
>  	}
> -	spin_unlock(&vop->reg_lock);
> +
> +	if (vop->data->afbc) {
> +		VOP_AFBC_SET(vop, enable, 0);
> +		vop->afbc_win = NULL;
> +	}
>  
>  	vop_cfg_done(vop);
>  
> +	spin_unlock(&vop->reg_lock);
> +
>  	/*
>  	 * At here, vop clock & iommu is enable, R/W vop regs would be safe.
>  	 */
> @@ -719,6 +758,32 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
>  		return -EINVAL;
>  	}
>  
> +	if (fb->modifier & DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP)) {
> +		struct vop *vop = to_vop(crtc);
> +
> +		if (!vop->data->afbc) {
> +			DRM_ERROR("VOP does not support AFBC\n");
> +			return -EINVAL;
> +		}
> +
> +		ret = vop_convert_afbc_format(fb->format->format);
> +		if (ret < 0)
> +			return ret;
> +
> +		if (state->src.x1 || state->src.y1) {
> +			DRM_ERROR("AFBC does not support offset display\n");
> +			DRM_ERROR("xpos=%d, ypos=%d, offset=%d\n",
> +				state->src.x1, state->src.y1, fb->offsets[0]);
> +			return -EINVAL;
> +		}
> +
> +		if (state->rotation && state->rotation != DRM_MODE_ROTATE_0) {
> +			DRM_ERROR("AFBC does not support rotation\n");
> +			DRM_ERROR("rotation=%d\n", state->rotation);
> +			return -EINVAL;
> +		}
> +	}
> +
>  	return 0;
>  }
>  
> @@ -732,6 +797,9 @@ static void vop_plane_atomic_disable(struct drm_plane *plane,
>  	if (!old_state->crtc)
>  		return;
>  
> +	if (vop->afbc_win == vop_win)
> +		vop->afbc_win = NULL;
> +
>  	spin_lock(&vop->reg_lock);
>  
>  	vop_win_disable(vop, win);
> @@ -774,6 +842,9 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
>  	if (WARN_ON(!vop->is_enabled))
>  		return;
>  
> +	if (vop->afbc_win == vop_win)
> +		vop->afbc_win = NULL;
> +
>  	if (!state->visible) {
>  		vop_plane_atomic_disable(plane, old_state);
>  		return;
> @@ -808,6 +879,20 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
>  
>  	spin_lock(&vop->reg_lock);
>  
> +	if (fb->modifier & DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP)) {
> +		int afbc_format = vop_convert_afbc_format(fb->format->format);
> +
> +		VOP_AFBC_SET(vop, format, afbc_format | 1 << 4);
> +		VOP_AFBC_SET(vop, hreg_block_split, 0);
> +		VOP_AFBC_SET(vop, win_sel, win_index);
> +		VOP_AFBC_SET(vop, hdr_ptr, dma_addr);
> +		VOP_AFBC_SET(vop, pic_size, act_info);
> +
> +		vop->afbc_win = vop_win;
> +
> +		pr_info("AFBC on plane %s\n", plane->name);
> +	}
> +
>  	VOP_WIN_SET(vop, win, format, format);
>  	VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
>  	VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
> @@ -1163,6 +1248,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
>  
>  	spin_lock(&vop->reg_lock);
>  
> +	VOP_AFBC_SET(vop, enable, vop->afbc_win ? 0x1 : 0);
>  	vop_cfg_done(vop);
>  
>  	spin_unlock(&vop->reg_lock);
> @@ -1471,7 +1557,8 @@ static int vop_create_crtc(struct vop *vop)
>  					       0, &vop_plane_funcs,
>  					       win_data->phy->data_formats,
>  					       win_data->phy->nformats,
> -					       NULL, win_data->type, NULL);
> +					       win_data->phy->format_modifiers,
> +					       win_data->type, NULL);
>  		if (ret) {
>  			DRM_DEV_ERROR(vop->dev, "failed to init plane %d\n",
>  				      ret);
> @@ -1511,7 +1598,8 @@ static int vop_create_crtc(struct vop *vop)
>  					       &vop_plane_funcs,
>  					       win_data->phy->data_formats,
>  					       win_data->phy->nformats,
> -					       NULL, win_data->type, NULL);
> +					       win_data->phy->format_modifiers,
> +					       win_data->type, NULL);
>  		if (ret) {
>  			DRM_DEV_ERROR(vop->dev, "failed to init overlay %d\n",
>  				      ret);
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 2149a889c29d..dc8b12025269 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -77,6 +77,16 @@ struct vop_misc {
>  	struct vop_reg global_regdone_en;
>  };
>  
> +struct vop_afbc {
> +	struct vop_reg enable;
> +	struct vop_reg win_sel;
> +	struct vop_reg format;
> +	struct vop_reg hreg_block_split;
> +	struct vop_reg pic_size;
> +	struct vop_reg hdr_ptr;
> +	struct vop_reg rstn;
> +};
> +
>  struct vop_intr {
>  	const int *intrs;
>  	uint32_t nintrs;
> @@ -128,6 +138,7 @@ struct vop_win_phy {
>  	const struct vop_scl_regs *scl;
>  	const uint32_t *data_formats;
>  	uint32_t nformats;
> +	const uint64_t *format_modifiers;
>  
>  	struct vop_reg enable;
>  	struct vop_reg gate;
> @@ -169,6 +180,7 @@ struct vop_data {
>  	const struct vop_output *output;
>  	const struct vop_win_yuv2yuv_data *win_yuv2yuv;
>  	const struct vop_win_data *win;
> +	const struct vop_afbc *afbc;
>  	unsigned int win_size;
>  
>  #define VOP_FEATURE_OUTPUT_RGB10	BIT(0)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 7b9c74750f6d..e9ff0c43c396 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -30,6 +30,12 @@
>  #define VOP_REG_MASK_SYNC(off, _mask, _shift) \
>  		_VOP_REG(off, _mask, _shift, true, false)
>  
> +static const uint64_t format_modifiers_afbc[] = {
> +	DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP),
> +	DRM_FORMAT_MOD_LINEAR,
> +	DRM_FORMAT_MOD_INVALID
> +};
> +
>  static const uint32_t formats_win_full[] = {
>  	DRM_FORMAT_XRGB8888,
>  	DRM_FORMAT_ARGB8888,
> @@ -667,6 +673,7 @@ static const struct vop_win_phy rk3368_win01_data = {
>  	.scl = &rk3288_win_full_scl,
>  	.data_formats = formats_win_full,
>  	.nformats = ARRAY_SIZE(formats_win_full),
> +	.format_modifiers = format_modifiers_afbc,
>  	.enable = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 0),
>  	.format = VOP_REG(RK3368_WIN0_CTRL0, 0x7, 1),
>  	.rb_swap = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 12),
> @@ -758,6 +765,16 @@ static const struct vop_data rk3366_vop = {
>  	.win_size = ARRAY_SIZE(rk3368_vop_win_data),
>  };
>  
> +static const struct vop_afbc rk3399_afbc = {
> +	.rstn = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 3),
> +	.enable = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 0),
> +	.win_sel = VOP_REG(RK3399_AFBCD0_CTRL, 0x3, 1),
> +	.format = VOP_REG(RK3399_AFBCD0_CTRL, 0x1f, 16),
> +	.hreg_block_split = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 21),
> +	.hdr_ptr = VOP_REG(RK3399_AFBCD0_HDR_PTR, 0xffffffff, 0),
> +	.pic_size = VOP_REG(RK3399_AFBCD0_PIC_SIZE, 0xffffffff, 0),
> +};
> +
>  static const struct vop_output rk3399_output = {
>  	.dp_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 16),
>  	.rgb_pin_pol = VOP_REG(RK3368_DSP_CTRL1, 0xf, 16),
> @@ -808,6 +825,7 @@ static const struct vop_data rk3399_vop_big = {
>  	.modeset = &rk3288_modeset,
>  	.output = &rk3399_output,
>  	.misc = &rk3368_misc,
> +	.afbc = &rk3399_afbc,
>  	.win = rk3368_vop_win_data,
>  	.win_size = ARRAY_SIZE(rk3368_vop_win_data),
>  	.win_yuv2yuv = rk3399_vop_big_win_yuv2yuv_data,
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3f987a..ba6caf06c824 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -742,6 +742,9 @@ extern "C" {
>   */
>  #define AFBC_FORMAT_MOD_BCH     (1ULL << 11)
>  
> +#define AFBC_FORMAT_MOD_ROCKCHIP \
> +	(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE)
> +
>  /*
>   * Allwinner tiled modifier
>   *
> -- 
> 2.17.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] drm/rockchip: Add AFBC support
From: Brian Starkey @ 2019-09-25  9:39 UTC (permalink / raw)
  To: Andrzej Pietrasiewicz
  Cc: nd, kernel@collabora.com, Tomeu Vizoso, David Airlie,
	Ezequiel Garcia, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, Maxime Ripard, Ayan Halder,
	Sean Paul, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190923122014.18229-1-andrzej.p@collabora.com>

Hi Andrzej,

Thanks for the patch, it's nice to see another AFBC implementation
coming in.

For future versions, could you please Cc ayan.halder@arm.com? It would
have been nice to have someone @arm.com on patches which use/impact
Arm modifiers. Sadly I don't know how to make get_maintainer.pl help
with that.

Some more comments below.

On Mon, Sep 23, 2019 at 02:20:13PM +0200, Andrzej Pietrasiewicz wrote:
> From: Ezequiel Garcia <ezequiel@collabora.com>
> 
> AFBC is a proprietary lossless image compression protocol and format.
> It helps reduce memory bandwidth of the graphics pipeline operations.
> This, in turn, improves power efficiency.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> [locking improvements]
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> [squashing the above, commit message and Rockchip AFBC modifier]
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 27 ++++++
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 94 ++++++++++++++++++++-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 +++
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 18 ++++
>  include/uapi/drm/drm_fourcc.h               |  3 +
>  5 files changed, 151 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 64ca87cf6d50..5178939a9c29 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -24,6 +24,27 @@ static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
>  	.dirty	       = drm_atomic_helper_dirtyfb,
>  };
>  
> +static int
> +rockchip_verify_afbc_mod(struct drm_device *dev,
> +			 const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> +	if (mode_cmd->modifier[0] &
> +	    ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP)) {
> +		DRM_DEV_ERROR(dev->dev,
> +			      "Unsupported format modifier 0x%llx\n",
> +			      mode_cmd->modifier[0]);
> +		return -EINVAL;
> +	}
> +
> +	if (mode_cmd->width > 2560) {
> +		DRM_DEV_ERROR(dev->dev,
> +			      "Unsupported width %d\n", mode_cmd->width);
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
>  static struct drm_framebuffer *
>  rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cmd,
>  		  struct drm_gem_object **obj, unsigned int num_planes)
> @@ -32,6 +53,12 @@ rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cm
>  	int ret;
>  	int i;
>  
> +	if (mode_cmd->modifier[0]) {
> +		ret = rockchip_verify_afbc_mod(dev, mode_cmd);
> +		if (ret)
> +			return ERR_PTR(ret);
> +	}
> +
>  	fb = kzalloc(sizeof(*fb), GFP_KERNEL);
>  	if (!fb)
>  		return ERR_PTR(-ENOMEM);
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 21b68eea46cc..50bf214d21da 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -46,6 +46,13 @@
>  		vop_reg_set(vop, &win->phy->scl->ext->name, \
>  			    win->base, ~0, v, #name)
>  
> +#define VOP_AFBC_SET(x, name, v) \
> +	do { \
> +		if (vop->data->afbc) \
> +			vop_reg_set(vop, &vop->data->afbc->name, \
> +				0, ~0, v, #name); \
> +	} while (0)
> +
>  #define VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, name, v) \
>  	do { \
>  		if (win_yuv2yuv && win_yuv2yuv->name.mask) \
> @@ -123,6 +130,8 @@ struct vop {
>  	struct drm_device *drm_dev;
>  	bool is_enabled;
>  
> +	struct vop_win *afbc_win;
> +
>  	struct completion dsp_hold_completion;
>  
>  	/* protected by dev->event_lock */
> @@ -245,6 +254,30 @@ static bool has_rb_swapped(uint32_t format)
>  	}
>  }
>  
> +#define AFBC_FMT_RGB565        0x0
> +#define AFBC_FMT_U8U8U8U8      0x5
> +#define AFBC_FMT_U8U8U8        0x4
> +
> +static int vop_convert_afbc_format(uint32_t format)
> +{

It would be great if you are able to follow the guidance Arm published
here: https://www.kernel.org/doc/html/latest/gpu/afbc.html, which will
help ensure interoperability and compatibility between different
devices/drivers. Hopefully it doesn't limit some use-cases for you -
if it does, let's discuss them.

Specifically, please take a look at the format list there. Some of
your formats below are not on the preferred interop list:

> +	switch (format) {
> +	case DRM_FORMAT_XRGB8888:

XRGB8888: Not preferred, as encoding the X channel is a waste of bits

> +	case DRM_FORMAT_ARGB8888:

ARGB8888: Not preferred as the channel order prevents YTR

> +	case DRM_FORMAT_XBGR8888:

XBGR8888: Not preferred, as encoding the X channel is a waste of bits

> +	case DRM_FORMAT_ABGR8888:
> +		return AFBC_FMT_U8U8U8U8;
> +	case DRM_FORMAT_RGB888:

RGB888: Not preferred as the channel order prevents YTR

> +	case DRM_FORMAT_BGR888:
> +		return AFBC_FMT_U8U8U8;
> +	case DRM_FORMAT_RGB565:

RGB565: Not preferred as the channel order prevents YTR

> +	case DRM_FORMAT_BGR565:
> +		return AFBC_FMT_RGB565;
> +	default:
> +		DRM_ERROR("unsupported afbc format[%08x]\n", format);
> +		return -EINVAL;
> +	}
> +}
> +
>  static enum vop_data_format vop_convert_format(uint32_t format)
>  {
>  	switch (format) {
> @@ -587,10 +620,16 @@ static int vop_enable(struct drm_crtc *crtc)
>  
>  		vop_win_disable(vop, win);
>  	}
> -	spin_unlock(&vop->reg_lock);
> +
> +	if (vop->data->afbc) {
> +		VOP_AFBC_SET(vop, enable, 0);
> +		vop->afbc_win = NULL;
> +	}
>  
>  	vop_cfg_done(vop);
>  
> +	spin_unlock(&vop->reg_lock);
> +
>  	/*
>  	 * At here, vop clock & iommu is enable, R/W vop regs would be safe.
>  	 */
> @@ -719,6 +758,32 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
>  		return -EINVAL;
>  	}
>  
> +	if (fb->modifier & DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP)) {
> +		struct vop *vop = to_vop(crtc);
> +
> +		if (!vop->data->afbc) {
> +			DRM_ERROR("VOP does not support AFBC\n");
> +			return -EINVAL;
> +		}
> +
> +		ret = vop_convert_afbc_format(fb->format->format);
> +		if (ret < 0)
> +			return ret;
> +
> +		if (state->src.x1 || state->src.y1) {
> +			DRM_ERROR("AFBC does not support offset display\n");
> +			DRM_ERROR("xpos=%d, ypos=%d, offset=%d\n",
> +				state->src.x1, state->src.y1, fb->offsets[0]);
> +			return -EINVAL;
> +		}
> +
> +		if (state->rotation && state->rotation != DRM_MODE_ROTATE_0) {
> +			DRM_ERROR("AFBC does not support rotation\n");
> +			DRM_ERROR("rotation=%d\n", state->rotation);
> +			return -EINVAL;
> +		}

It may be a good idea to check your framebuffer size, as the required
framebuffer size is different for AFBC. You can refer to mali-dp for
the calculations - perhaps even share the code.

> +	}
> +
>  	return 0;
>  }
>  
> @@ -732,6 +797,9 @@ static void vop_plane_atomic_disable(struct drm_plane *plane,
>  	if (!old_state->crtc)
>  		return;
>  
> +	if (vop->afbc_win == vop_win)
> +		vop->afbc_win = NULL;
> +
>  	spin_lock(&vop->reg_lock);
>  
>  	vop_win_disable(vop, win);
> @@ -774,6 +842,9 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
>  	if (WARN_ON(!vop->is_enabled))
>  		return;
>  
> +	if (vop->afbc_win == vop_win)
> +		vop->afbc_win = NULL;
> +
>  	if (!state->visible) {
>  		vop_plane_atomic_disable(plane, old_state);
>  		return;
> @@ -808,6 +879,20 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
>  
>  	spin_lock(&vop->reg_lock);
>  
> +	if (fb->modifier & DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP)) {
> +		int afbc_format = vop_convert_afbc_format(fb->format->format);
> +
> +		VOP_AFBC_SET(vop, format, afbc_format | 1 << 4);
> +		VOP_AFBC_SET(vop, hreg_block_split, 0);
> +		VOP_AFBC_SET(vop, win_sel, win_index);
> +		VOP_AFBC_SET(vop, hdr_ptr, dma_addr);
> +		VOP_AFBC_SET(vop, pic_size, act_info);
> +
> +		vop->afbc_win = vop_win;
> +
> +		pr_info("AFBC on plane %s\n", plane->name);
> +	}
> +
>  	VOP_WIN_SET(vop, win, format, format);
>  	VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
>  	VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
> @@ -1163,6 +1248,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
>  
>  	spin_lock(&vop->reg_lock);
>  
> +	VOP_AFBC_SET(vop, enable, vop->afbc_win ? 0x1 : 0);
>  	vop_cfg_done(vop);
>  
>  	spin_unlock(&vop->reg_lock);
> @@ -1471,7 +1557,8 @@ static int vop_create_crtc(struct vop *vop)
>  					       0, &vop_plane_funcs,
>  					       win_data->phy->data_formats,
>  					       win_data->phy->nformats,
> -					       NULL, win_data->type, NULL);
> +					       win_data->phy->format_modifiers,
> +					       win_data->type, NULL);
>  		if (ret) {
>  			DRM_DEV_ERROR(vop->dev, "failed to init plane %d\n",
>  				      ret);
> @@ -1511,7 +1598,8 @@ static int vop_create_crtc(struct vop *vop)
>  					       &vop_plane_funcs,
>  					       win_data->phy->data_formats,
>  					       win_data->phy->nformats,
> -					       NULL, win_data->type, NULL);
> +					       win_data->phy->format_modifiers,
> +					       win_data->type, NULL);
>  		if (ret) {
>  			DRM_DEV_ERROR(vop->dev, "failed to init overlay %d\n",
>  				      ret);
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 2149a889c29d..dc8b12025269 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -77,6 +77,16 @@ struct vop_misc {
>  	struct vop_reg global_regdone_en;
>  };
>  
> +struct vop_afbc {
> +	struct vop_reg enable;
> +	struct vop_reg win_sel;
> +	struct vop_reg format;
> +	struct vop_reg hreg_block_split;
> +	struct vop_reg pic_size;
> +	struct vop_reg hdr_ptr;
> +	struct vop_reg rstn;
> +};
> +
>  struct vop_intr {
>  	const int *intrs;
>  	uint32_t nintrs;
> @@ -128,6 +138,7 @@ struct vop_win_phy {
>  	const struct vop_scl_regs *scl;
>  	const uint32_t *data_formats;
>  	uint32_t nformats;
> +	const uint64_t *format_modifiers;
>  
>  	struct vop_reg enable;
>  	struct vop_reg gate;
> @@ -169,6 +180,7 @@ struct vop_data {
>  	const struct vop_output *output;
>  	const struct vop_win_yuv2yuv_data *win_yuv2yuv;
>  	const struct vop_win_data *win;
> +	const struct vop_afbc *afbc;
>  	unsigned int win_size;
>  
>  #define VOP_FEATURE_OUTPUT_RGB10	BIT(0)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 7b9c74750f6d..e9ff0c43c396 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -30,6 +30,12 @@
>  #define VOP_REG_MASK_SYNC(off, _mask, _shift) \
>  		_VOP_REG(off, _mask, _shift, true, false)
>  
> +static const uint64_t format_modifiers_afbc[] = {
> +	DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP),
> +	DRM_FORMAT_MOD_LINEAR,
> +	DRM_FORMAT_MOD_INVALID
> +};
> +
>  static const uint32_t formats_win_full[] = {
>  	DRM_FORMAT_XRGB8888,
>  	DRM_FORMAT_ARGB8888,
> @@ -667,6 +673,7 @@ static const struct vop_win_phy rk3368_win01_data = {
>  	.scl = &rk3288_win_full_scl,
>  	.data_formats = formats_win_full,
>  	.nformats = ARRAY_SIZE(formats_win_full),
> +	.format_modifiers = format_modifiers_afbc,

I may have missed something, but don't you need to implement the
format_mod_supported hook on the plane to expose the modifiers to
userspace?

>  	.enable = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 0),
>  	.format = VOP_REG(RK3368_WIN0_CTRL0, 0x7, 1),
>  	.rb_swap = VOP_REG(RK3368_WIN0_CTRL0, 0x1, 12),
> @@ -758,6 +765,16 @@ static const struct vop_data rk3366_vop = {
>  	.win_size = ARRAY_SIZE(rk3368_vop_win_data),
>  };
>  
> +static const struct vop_afbc rk3399_afbc = {
> +	.rstn = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 3),
> +	.enable = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 0),
> +	.win_sel = VOP_REG(RK3399_AFBCD0_CTRL, 0x3, 1),
> +	.format = VOP_REG(RK3399_AFBCD0_CTRL, 0x1f, 16),
> +	.hreg_block_split = VOP_REG(RK3399_AFBCD0_CTRL, 0x1, 21),
> +	.hdr_ptr = VOP_REG(RK3399_AFBCD0_HDR_PTR, 0xffffffff, 0),
> +	.pic_size = VOP_REG(RK3399_AFBCD0_PIC_SIZE, 0xffffffff, 0),
> +};
> +
>  static const struct vop_output rk3399_output = {
>  	.dp_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 16),
>  	.rgb_pin_pol = VOP_REG(RK3368_DSP_CTRL1, 0xf, 16),
> @@ -808,6 +825,7 @@ static const struct vop_data rk3399_vop_big = {
>  	.modeset = &rk3288_modeset,
>  	.output = &rk3399_output,
>  	.misc = &rk3368_misc,
> +	.afbc = &rk3399_afbc,
>  	.win = rk3368_vop_win_data,
>  	.win_size = ARRAY_SIZE(rk3368_vop_win_data),
>  	.win_yuv2yuv = rk3399_vop_big_win_yuv2yuv_data,
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3f987a..ba6caf06c824 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -742,6 +742,9 @@ extern "C" {
>   */
>  #define AFBC_FORMAT_MOD_BCH     (1ULL << 11)
>  
> +#define AFBC_FORMAT_MOD_ROCKCHIP \
> +	(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE)
> +

As Neil said, this seems redundant. If you would like the convenience
macro, stick it in the Rockchip driver rather than UAPI.

Also, if your hardware is able to support YTR, I would recommend
enabling it.

Best regards,
-Brian

>  /*
>   * Allwinner tiled modifier
>   *
> -- 
> 2.17.1
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] mm, debug, kasan: save and dump freeing stack trace for kasan
From: Andrey Ryabinin @ 2019-09-25  9:41 UTC (permalink / raw)
  To: Vlastimil Babka, Walter Wu
  Cc: wsd_upstream, Arnd Bergmann, linux-mm, Andrey Konovalov,
	linux-mediatek, linux-kernel, kasan-dev, Martin Schwidefsky,
	Alexander Potapenko, linux-arm-kernel, Matthias Brugger, Qian Cai,
	Andrew Morton, Dmitry Vyukov
In-Reply-To: <d98bf550-367d-0744-025a-52307248ec82@suse.cz>



On 9/23/19 11:20 AM, Vlastimil Babka wrote:
> On 9/16/19 5:57 PM, Andrey Ryabinin wrote:
>> I'd rather keep all logic in one place, i.e. "if (!page_owner_disabled && (IS_ENABLED(CONFIG_KASAN) || debug_pagealloc_enabled())"
>> With this no changes in early_debug_pagealloc() required and CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y should also work correctly.
> 
> OK.
> 
> ----8<----
> 
> From 7437c43f02682fdde5680fa83e87029f7529e222 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka <vbabka@suse.cz>
> Date: Mon, 16 Sep 2019 11:28:19 +0200
> Subject: [PATCH] mm, debug, kasan: save and dump freeing stack trace for kasan
> 
> The commit "mm, page_owner, debug_pagealloc: save and dump freeing stack trace"
> enhanced page_owner to also store freeing stack trace, when debug_pagealloc is
> also enabled. KASAN would also like to do this [1] to improve error reports to
> debug e.g. UAF issues. This patch therefore introduces a helper config option
> PAGE_OWNER_FREE_STACK, which is enabled when PAGE_OWNER and either of
> DEBUG_PAGEALLOC or KASAN is enabled. Boot-time, the free stack saving is
> enabled when booting a KASAN kernel with page_owner=on, or non-KASAN kernel
> with debug_pagealloc=on and page_owner=on.
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=203967
> 
> Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> Suggested-by: Walter Wu <walter-zh.wu@mediatek.com>
> Suggested-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---

Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] drm/rockchip: Add AFBC support
From: Andrzej Pietrasiewicz @ 2019-09-25  9:42 UTC (permalink / raw)
  To: Brian Starkey
  Cc: nd, kernel@collabora.com, Tomeu Vizoso, David Airlie,
	Ezequiel Garcia, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	linux-rockchip@lists.infradead.org, Maxime Ripard, Ayan Halder,
	Sean Paul, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190925093913.z4vduybwcokn3awi@DESKTOP-E1NTVVP.localdomain>

Hi Brian,

W dniu 25.09.2019 o 11:39, Brian Starkey pisze:
> Hi Andrzej,
> 
> Thanks for the patch, it's nice to see another AFBC implementation
> coming in.
> 

I did a false start, though. But the work is in progress. Thanks for the review, 
anyway.

> For future versions, could you please Cc ayan.halder@arm.com? It would
> have been nice to have someone @arm.com on patches which use/impact
> Arm modifiers. Sadly I don't know how to make get_maintainer.pl help

Of course.

Andrzej

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] counter: stm32: clean up indentation issue
From: Colin King @ 2019-09-25  9:51 UTC (permalink / raw)
  To: Fabrice Gasnier, William Breathitt Gray, Maxime Coquelin,
	Alexandre Torgue, linux-iio, linux-stm32, linux-arm-kernel
  Cc: kernel-janitors, linux-kernel

From: Colin Ian King <colin.king@canonical.com>

There is an if statement that is indented one level too deeply,
remove the extraneous tabs.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 drivers/counter/stm32-timer-cnt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index 644ba18a72ad..613dcccf79e1 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -219,8 +219,8 @@ static ssize_t stm32_count_enable_write(struct counter_device *counter,
 
 	if (enable) {
 		regmap_read(priv->regmap, TIM_CR1, &cr1);
-			if (!(cr1 & TIM_CR1_CEN))
-				clk_enable(priv->clk);
+		if (!(cr1 & TIM_CR1_CEN))
+			clk_enable(priv->clk);
 
 		regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN,
 				   TIM_CR1_CEN);
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related


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