linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Wahren <stefan.wahren@i2se.com>
To: Ojaswin Mujoo <ojaswin98@gmail.com>
Cc: nsaenz@kernel.org, gregkh@linuxfoundation.org,
	dan.carpenter@oracle.com, phil@raspberrypi.com,
	linux-arm-kernel@lists.infradead.org,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] staging: vchiq: Replace global state with per device state
Date: Mon, 1 Nov 2021 19:58:00 +0100	[thread overview]
Message-ID: <e3caf226-2133-c570-b775-17ed3c7fbd02@i2se.com> (raw)
In-Reply-To: <20211101172843.GA17771@ojas>

Hi Ojawin,

Am 01.11.21 um 18:31 schrieb Ojaswin Mujoo:
> On Mon, Nov 01, 2021 at 01:19:17PM +0100, Stefan Wahren wrote:
>> Hi Ojaswin,
>>
>> Am 01.11.21 um 12:09 schrieb Ojaswin Mujoo:
>>> Currently, the driver has a global g_state variable which is initialised
>>> during probe and directly used all over the driver code. However, this
>>> prevents the driver to support multiple VideoCore VPUs at the same time.
>>>
>>> Replace this global state with a per device state which is initialised
>>> and allocated during probing.
>>>
>>> Signed-off-by: Ojaswin Mujoo <ojaswin98@gmail.com>
>> ...
>>>  
>>>  /*
>>> @@ -1763,6 +1795,7 @@ static int vchiq_probe(struct platform_device *pdev)
>>>  	struct device_node *fw_node;
>>>  	const struct of_device_id *of_id;
>>>  	struct vchiq_drvdata *drvdata;
>>> +	struct vchiq_device *vchiq_dev;
>>>  	int err;
>>>  
>>>  	of_id = of_match_node(vchiq_of_match, pdev->dev.of_node);
>>> @@ -1784,7 +1817,18 @@ static int vchiq_probe(struct platform_device *pdev)
>>>  
>>>  	platform_set_drvdata(pdev, drvdata);
>>>  
>>> -	err = vchiq_platform_init(pdev, &g_state);
>>> +	vchiq_dev = kzalloc(sizeof(struct vchiq_device), GFP_KERNEL);
>>> +	vchiq_dev->state = kzalloc(sizeof(struct vchiq_state), GFP_KERNEL);
>>> +	vchiq_dev->vchiq_pdev = *pdev;
>>> +
>>> +	g_state = vchiq_dev->state;
>>> +
>> just a quick idea: how about storing the global state within vchiq_drvdata?
>>
>> So there is no need to reinvent somekind of vchiq device which is the
>> "same" as the platform device. After that you are able to access the
>> private driver data via platform_get_drvdata().
> Hi Stefan, 
>
> Thank for looking into this. I agree that the vchiq_device is just a
> sorta extension of the pdev. However, regarding using the drvdata, I had
> some questions.
>
> So I understand the purpose of this patch is to make sure our driver is
> able to support multiple devices, that is it can work with say, an SoC
> with 2 VideoCore VPUs. In this case, we would need to maintain 2 states
> for each VPU instead of a global state, however if we use something like
> the following:
>
>  	drvdata = (struct vchiq_drvdata *)of_id->data;
>   drvdata->state = kzalloc(sizeof(struct vchiq_state), GFP_KERNEL);
> 	platform_set_drvdata(pdev, drvdata);
> 		

no, this wasn't my intention. We need a new container struct (maybe
vchiq_priv or so) which stores the g_state and the platform data from
the devicetree of_id->data. At first the probe function allocates this
struct and then we fill it with g_state and the devicetree stuff. After
that we attach it to the platform device.

Regards


  reply	other threads:[~2021-11-01 18:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-01 11:09 [PATCH 0/1] vchiq: Replacing global structs with per device Ojaswin Mujoo
2021-11-01 11:09 ` [PATCH 1/1] staging: vchiq: Replace global state with per device state Ojaswin Mujoo
2021-11-01 12:19   ` Stefan Wahren
2021-11-01 17:31     ` Ojaswin Mujoo
2021-11-01 18:58       ` Stefan Wahren [this message]
2021-11-01 16:07   ` kernel test robot
2021-11-01 16:45   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3caf226-2133-c570-b775-17ed3c7fbd02@i2se.com \
    --to=stefan.wahren@i2se.com \
    --cc=dan.carpenter@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=nsaenz@kernel.org \
    --cc=ojaswin98@gmail.com \
    --cc=phil@raspberrypi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).