All of lore.kernel.org
 help / color / mirror / Atom feed
From: majun258@huawei.com (majun (F))
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] irq/mbigen:Fix the problem of IO remap for duplicated physical address in mbigen driver
Date: Wed, 3 Feb 2016 10:31:52 +0800	[thread overview]
Message-ID: <56B16698.6050509@huawei.com> (raw)
In-Reply-To: <20160202114340.GA28839@leverpostej>



? 2016/2/2 19:43, Mark Rutland ??:
> On Tue, Feb 02, 2016 at 06:25:53PM +0800, majun (F) wrote:
>> Hi Mark:
>>
>> ? 2016/2/1 21:25, Mark Rutland ??:
>>> On Mon, Feb 01, 2016 at 09:06:38PM +0800, majun (F) wrote:
>>>>
>>>>
>>>> ? 2016/2/1 19:57, Mark Rutland ??:
>>>>> On Mon, Feb 01, 2016 at 07:44:54PM +0800, MaJun wrote:
>>>>>> From: Ma Jun <majun258@huawei.com>
>>>>>>
>>>>>> For mbigen module, there is a special case that more than one mbigen 
>>>>>> device nodes use the same reg definition in DTS when these devices
>>>>>> exist in the same mbigen hardware module. 
>>>>>>
>>>>>> mbigen_dev1:intc_dev1 {
>>>>>> 	...
>>>>>> 	reg = <0x0 0xc0080000 0x0 0x10000>;
>>>>>> 	...
>>>>>> };
>>>>>>
>>>>>> mbigen_dev2:intc_dev2 {
>>>>>> 	...
>>>>>> 	reg = <0x0 0xc0080000 0x0 0x10000>;
>>>>>> 	...
>>>>>> };
>>>>>
>>>>> This doesn't sound right. If they exist in the same place, and have the
>>>>> same reg, they _are_ the same device.
>>>>>
>>>>> You'll need to explain this better.
>>>>>
>>>>
>>>> For a mbigen hardware module which connecte with several devices,
>>>> because these devices has different device ID,
>>>> I need to define a device node for each device in DTS file.
>>>>
>>>> 	mbigen
>>>> 	|
>>>> ------------------
>>>> | 	| 	|
>>>> dev1 	dev2 	dev3
>>>>
>>>> Because of register layout,the registers related with these devices
>>>> are put together, I can't split them clearly.
>>>> So, I only make these devices which connect with
>>>> same mbigen hardware module usethe same address.
>>>
>>> This sounds like we've either mis-described the mbigen in the binding,
>>> or we're mis-describing the relationship with the devices.
>>>
>>
>> Sorry, I didn't express myself clearly.
>>
>> For example, a mbigen hardware module can support several peripheral devices
>> with different device ID.
>>
>> |-----------------------|-
>> |	mbigen		|
>> |-----------------------|-
>>  |       |        |
>> dev1    dev2     dev3
>>
>> To simplify the mbigen drvier,
>> I didn't use the whole mbigen module as a mbgien device, but use
>> the register collections(vector, trigger type,status etc.) corresponding
>> to a peripheral device as a mbigen device.
>> So, mbigen device is a logical conception or logical device.
> 
>>From the above, it sounds like the DT representation is not an accurate
> representation of the hardware. We should describe the _whole_ mbigen,
> not portions thereof. Trying to describe it piecemeal leads to problems
> like this one.
> 
> I don't understand the rationale for describing the mbigen as separate
> nodes. Above you mention that we "need to define a device node for each
> device", but I don't see why that's necessary. Why do you believe we
> need an mbigen node per client device?
> 
> As far as I can tell, we should be able to map an arbitrary
> interrupt-specifier to a particular MSI (complete with device id) within
> the mbigen driver. We just need to define the full set of MSIs the
> mbigen owns.
> 

mbigen device is a interrupt controller, it is also a ITS device for ITS module.
So, we need to register the each mbigen device to ITS with a unique ID.
Based on the current MSI/ITS driver, I can't register whole mbigen module which
contains several mbigen devices at one time. Because they have different device ID.

I don't know whether this explanation is clear or not.
I think Marc can explain this well.

Marc, would you please help me explain this?  or, do you have any opinion about this ?

>> Now, a mbigen hardware module contains several logical mbigen device.
>>
>> -------------------------------
>> |mgn_dev1  mgn_dev2  mgn_dev3 |
>> |-----------------------------|
>>    |          |        |
>> dev1	    dev2      dev3
>>
>> So,mgn_dev1, mgn_dev2 and mgn_dev3 exist in same mbigen hardware module,
>> and,they use the same reg address region,that is adress of mbigen hardware module.
>>
>> For this case, I think the question is can we map an reg address
>> region more than one time?
> 
> As above, I think we've mis-described the hardware. Rather than making
> things simpler, this has resulted in problems like this one.
> 
> We should not map a reg region more than once. Even if it's technically
> possible to do so, I do not believe that would be the right solution
> here. Implicitly sharing resources (e.g. portions of the mbigen control
> registers) is inevitably going to lead to more problems later on.

Because we only need to write 1 into corresponding bit of status
register to clear interrupt status during runtime,I think we don't
need to worry about this.

Thanks!
Ma Jun


> 
> Mark.
> 
> .
> 

  reply	other threads:[~2016-02-03  2:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 11:44 [RFC PATCH] irq/mbigen:Fix the problem of IO remap for duplicated physical address in mbigen driver MaJun
2016-02-01 11:57 ` Mark Rutland
2016-02-01 13:06   ` majun (F)
2016-02-01 13:25     ` Mark Rutland
2016-02-02 10:25       ` majun (F)
2016-02-02 11:43         ` Mark Rutland
2016-02-03  2:31           ` majun (F) [this message]
2016-02-03 11:16             ` Mark Rutland
2016-02-16  7:54               ` majun (F)
2016-03-17  8:33 [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem " MaJun
2016-03-17  8:33 ` MaJun
2016-03-17  8:34 ` [PATCH v3 1/2] irqchip/mbigen:Change the mbigen node definition in dt binding file MaJun
2016-03-17  8:34   ` MaJun
2016-03-21 10:30   ` [tip:irq/urgent] irqchip/mbigen: Adjust DT bindings to handle multiple devices in a module tip-bot for MaJun
2016-03-17  8:34 ` [PATCH v3 2/2] irqchip/mbigen:Change the mbigen driver based on the new mbigen node definition MaJun
2016-03-17  8:34   ` MaJun
2016-03-21 10:30   ` [tip:irq/urgent] irqchip/mbigen: Handle multiple device nodes in a mbigen module tip-bot for MaJun
2016-03-21 10:29 ` [PATCH v3 0/2] irqchip/mbigen: fix the IO remap problem in mbigen driver Thomas Gleixner
2016-03-21 10:29   ` Thomas Gleixner
2016-03-22  3:10   ` majun (F)
2016-03-22  3:10     ` majun (F)
2016-05-05 14:49     ` Marc Zyngier
2016-05-05 14:49       ` Marc Zyngier
2016-05-06  1:12       ` majun (F)
2016-05-06  1:12         ` majun (F)
2016-05-06  7:32         ` Marc Zyngier
2016-05-06  7:32           ` Marc Zyngier
2016-05-06  9:07           ` majun (F)
2016-05-06  9:07             ` majun (F)

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=56B16698.6050509@huawei.com \
    --to=majun258@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.