All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhou Wang <wangzhou1@hisilicon.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: devicetree@vger.kernel.org, liguozhu@hisilicon.com,
	xuwei5@hisilicon.com, linux-mtd@lists.infradead.org,
	haojian.zhuang@gmail.com, caizhiyong@huawei.com,
	yubingxu@hisilicon.com, David Woodhouse <dwmw2@infradead.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 1/2] mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc
Date: Thu, 15 Jan 2015 09:27:14 +0800	[thread overview]
Message-ID: <54B71772.9080601@hisilicon.com> (raw)
In-Reply-To: <20150114192510.GY9759@ld-irv-0074>

On 2015/1/15 3:25, Brian Norris wrote:
> On Wed, Jan 14, 2015 at 08:34:39PM +0800, Zhou Wang wrote:
>> On 2015/1/13 11:58, Brian Norris wrote:
>>> On Mon, Jan 12, 2015 at 03:28:53PM +0800, Zhou Wang wrote:
>>>> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>>> +	chip->IO_ADDR_R = chip->IO_ADDR_W = devm_ioremap_resource(dev, res);
>>>
>>> Hmm, do you really have to reuse IO_ADDR_{R,W} here? Those are only
>>> targeted for NAND systems which have a direct MMIO mapping to the NAND
>>> I/O pins. See nand_base's {read,write}_buf() and read_{byte,word}()
>>> implementations. But you override those.
>>
>> There is a hardware buffer in this NAND controller, and the buffer can be
>> accessed as MMIO.
> 
> Sure.
> 
>> IO_ADDR_R/W just indicates the base address of this buffer.
> 
> But I was noting that IO_ADDR_{R,W} actually serve a very particular
> purpose in nand_base.c, which seems distinct from your HW buffer.
> 
>> Maybe I need to use a void __iomem pointer stored in my host struct to use
>> this buffer instead of IO_ADDR_R/W as you said below here?
> 
> Yes, I think that would be better.

OK, I will do as this in next version, Thanks!

> 
>>> It's best if it's obvious if nand_base is somehow inadvertently using
>>> these pointers. So leaving them NULL is helpful.
>>>
>>> As an alternative, you can just stash another private void __iomem
>>> pointer in you your host struct.
> 
> Thanks,
> Brian

Thanks for your reply!
Zhou Wang

> 
> .
> 

WARNING: multiple messages have this Message-ID (diff)
From: wangzhou1@hisilicon.com (Zhou Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 1/2] mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc
Date: Thu, 15 Jan 2015 09:27:14 +0800	[thread overview]
Message-ID: <54B71772.9080601@hisilicon.com> (raw)
In-Reply-To: <20150114192510.GY9759@ld-irv-0074>

On 2015/1/15 3:25, Brian Norris wrote:
> On Wed, Jan 14, 2015 at 08:34:39PM +0800, Zhou Wang wrote:
>> On 2015/1/13 11:58, Brian Norris wrote:
>>> On Mon, Jan 12, 2015 at 03:28:53PM +0800, Zhou Wang wrote:
>>>> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>>> +	chip->IO_ADDR_R = chip->IO_ADDR_W = devm_ioremap_resource(dev, res);
>>>
>>> Hmm, do you really have to reuse IO_ADDR_{R,W} here? Those are only
>>> targeted for NAND systems which have a direct MMIO mapping to the NAND
>>> I/O pins. See nand_base's {read,write}_buf() and read_{byte,word}()
>>> implementations. But you override those.
>>
>> There is a hardware buffer in this NAND controller, and the buffer can be
>> accessed as MMIO.
> 
> Sure.
> 
>> IO_ADDR_R/W just indicates the base address of this buffer.
> 
> But I was noting that IO_ADDR_{R,W} actually serve a very particular
> purpose in nand_base.c, which seems distinct from your HW buffer.
> 
>> Maybe I need to use a void __iomem pointer stored in my host struct to use
>> this buffer instead of IO_ADDR_R/W as you said below here?
> 
> Yes, I think that would be better.

OK, I will do as this in next version, Thanks!

> 
>>> It's best if it's obvious if nand_base is somehow inadvertently using
>>> these pointers. So leaving them NULL is helpful.
>>>
>>> As an alternative, you can just stash another private void __iomem
>>> pointer in you your host struct.
> 
> Thanks,
> Brian

Thanks for your reply!
Zhou Wang

> 
> .
> 

WARNING: multiple messages have this Message-ID (diff)
From: Zhou Wang <wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
To: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	haojian.zhuang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	caizhiyong-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	yubingxu-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
	liguozhu-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org
Subject: Re: [PATCH v6 1/2] mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc
Date: Thu, 15 Jan 2015 09:27:14 +0800	[thread overview]
Message-ID: <54B71772.9080601@hisilicon.com> (raw)
In-Reply-To: <20150114192510.GY9759@ld-irv-0074>

On 2015/1/15 3:25, Brian Norris wrote:
> On Wed, Jan 14, 2015 at 08:34:39PM +0800, Zhou Wang wrote:
>> On 2015/1/13 11:58, Brian Norris wrote:
>>> On Mon, Jan 12, 2015 at 03:28:53PM +0800, Zhou Wang wrote:
>>>> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>>> +	chip->IO_ADDR_R = chip->IO_ADDR_W = devm_ioremap_resource(dev, res);
>>>
>>> Hmm, do you really have to reuse IO_ADDR_{R,W} here? Those are only
>>> targeted for NAND systems which have a direct MMIO mapping to the NAND
>>> I/O pins. See nand_base's {read,write}_buf() and read_{byte,word}()
>>> implementations. But you override those.
>>
>> There is a hardware buffer in this NAND controller, and the buffer can be
>> accessed as MMIO.
> 
> Sure.
> 
>> IO_ADDR_R/W just indicates the base address of this buffer.
> 
> But I was noting that IO_ADDR_{R,W} actually serve a very particular
> purpose in nand_base.c, which seems distinct from your HW buffer.
> 
>> Maybe I need to use a void __iomem pointer stored in my host struct to use
>> this buffer instead of IO_ADDR_R/W as you said below here?
> 
> Yes, I think that would be better.

OK, I will do as this in next version, Thanks!

> 
>>> It's best if it's obvious if nand_base is somehow inadvertently using
>>> these pointers. So leaving them NULL is helpful.
>>>
>>> As an alternative, you can just stash another private void __iomem
>>> pointer in you your host struct.
> 
> Thanks,
> Brian

Thanks for your reply!
Zhou Wang

> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2015-01-15  1:27 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-12  7:28 [PATCH v6 0/2] mtd: hisilicon: add a new driver for NAND controller of hisilicon hip04 Soc Zhou Wang
2015-01-12  7:28 ` Zhou Wang
2015-01-12  7:28 ` Zhou Wang
2015-01-12  7:28 ` [PATCH v6 1/2] mtd: hisilicon: add a new NAND controller driver for " Zhou Wang
2015-01-12  7:28   ` Zhou Wang
2015-01-12  7:28   ` Zhou Wang
2015-01-12  8:21   ` Arnd Bergmann
2015-01-12  8:21     ` Arnd Bergmann
2015-01-12  8:21     ` Arnd Bergmann
2015-01-12  9:18     ` Zhou Wang
2015-01-12  9:18       ` Zhou Wang
2015-01-12  9:18       ` Zhou Wang
2015-01-13  3:58   ` Brian Norris
2015-01-13  3:58     ` Brian Norris
2015-01-13  3:58     ` Brian Norris
2015-01-14 12:34     ` Zhou Wang
2015-01-14 12:34       ` Zhou Wang
2015-01-14 12:34       ` Zhou Wang
2015-01-14 19:25       ` Brian Norris
2015-01-14 19:25         ` Brian Norris
2015-01-14 19:25         ` Brian Norris
2015-01-15  1:27         ` Zhou Wang [this message]
2015-01-15  1:27           ` Zhou Wang
2015-01-15  1:27           ` Zhou Wang
2015-01-13  4:02   ` Brian Norris
2015-01-13  4:02     ` Brian Norris
2015-01-13  4:02     ` Brian Norris
2015-01-14 12:45     ` Zhou Wang
2015-01-14 12:45       ` Zhou Wang
2015-01-14 12:45       ` Zhou Wang
2015-01-12  7:28 ` [PATCH v6 2/2] mtd: hisilicon: add device tree binding documentation Zhou Wang
2015-01-12  7:28   ` Zhou Wang
2015-01-12  7:28   ` Zhou Wang

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=54B71772.9080601@hisilicon.com \
    --to=wangzhou1@hisilicon.com \
    --cc=caizhiyong@huawei.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=haojian.zhuang@gmail.com \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=xuwei5@hisilicon.com \
    --cc=yubingxu@hisilicon.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 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.