linux-spi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
To: Andy Shevchenko
	<andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	<dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>,
	Linux Documentation List
	<linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	<tthayer.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Axel Lin <axel.lin-8E1dMatC8ynQT0dZR+AlfA@public.gmane.org>,
	<baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>,
	Andy Shevchenko
	<andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Jingoo Han <jg1.han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Subject: Re: [RFC/PATCHv2 3/3] spi: dw-spi: Pointers select 16b vs. 32b DesignWare access
Date: Mon, 9 Mar 2015 14:47:07 -0500	[thread overview]
Message-ID: <54FDF8BB.4050202@opensource.altera.com> (raw)
In-Reply-To: <CAHp75Vf6dgobzZyJxu8eiqGgC7FRrwLCmyMf5Agk6S3jHDj4bw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>



On 03/09/2015 01:54 PM, Andy Shevchenko wrote:
> On Mon, Mar 9, 2015 at 8:01 PM, Thor Thayer
> <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org> wrote:
>>
>>
>> On 03/07/2015 01:52 PM, Andy Shevchenko wrote:
>>>
>>> On Sat, Mar 7, 2015 at 1:46 AM,  <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org> wrote:
>>>>
>>>> From: Thor Thayer <tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>>>>
>>>> Altera's Arria10 SoC interconnect requires a 32 bit write for APB
>>>> peripherals. The current spi-dw driver uses 16bit accesses in
>>>> some locations. Use function pointers to support 32 bit accesses
>>>> but retain legacy 16 bit access.
>
>>>> --- a/drivers/spi/spi-dw-mmio.c
>>>> +++ b/drivers/spi/spi-dw-mmio.c
>>>> @@ -76,8 +76,13 @@ static int dw_spi_mmio_probe(struct platform_device
>>>> *pdev)
>>>>
>>>>           num_cs = 4;
>>>>
>>>> -       if (pdev->dev.of_node)
>>>> +       if (pdev->dev.of_node) {
>>>>                   of_property_read_u32(pdev->dev.of_node, "num-cs",
>>>> &num_cs);
>>>> +               if (of_property_read_bool(pdev->dev.of_node,
>>>> "32bit_access")) {
>
> "32bit-access"
>

Thanks. I will make the change.

>>>> +                       dws->read_w = dw_readw32;
>>>> +                       dws->write_w = dw_writew32;
>>>
>>>
>>> Can we use just  readw/writew (w/o underscores) as names for the
>>> accessors?
>>>
>>
>> I tried this initially and got a namespace conflict with the readw & write2
>> macros.
>> macro writew passed 3 arguments, but takes just 2
>> macro readw passed 2 arguments, but takes just 1
>
> Might be I wasn't clear enough. I meant
>
> dws->readw = …
> dws->writew = …
>

Yes, we agree. These are exactly what I was using when I saw the error.

>>>> --- a/drivers/spi/spi-dw.h
>>>> +++ b/drivers/spi/spi-dw.h
>>>> @@ -141,6 +141,8 @@ struct dw_spi {
>>>>    #ifdef CONFIG_DEBUG_FS
>>>>           struct dentry *debugfs;
>>>>    #endif
>>>> +       u16 (*read_w)(struct dw_spi *dws, u32 offset);
>>>> +       void (*write_w)(struct dw_spi *dws, u32 offset, u16 val);
>
> readw
> writew
>
> As I can see there are no such field names in struct dw_spi.
>

Yes. This seems safe but I still see the macro conflict which is strange 
to me. Like you, I initially used the dws->readw and dws->writew because 
I didn't see any conflicting field names.

Are readw & writew reserved variable names?

>>>>    };
>>>>
>>>>    static inline u32 dw_readl(struct dw_spi *dws, u32 offset)
>>>> @@ -163,6 +165,16 @@ static inline void dw_writew(struct dw_spi *dws, u32
>>>> offset, u16 val)
>>>>           __raw_writew(val, dws->regs + offset);
>>>>    }
>>>>
>>>> +static inline u16 dw_readw32(struct dw_spi *dws, u32 offset)
>>>> +{
>>>> +       return (u16)__raw_readl(dws->regs + offset)
>
> Maybe return dw_readl(dws, offset);
>
>>>> +}
>>>> +
>>>> +static inline void dw_writew32(struct dw_spi *dws, u32 offset, u16 val)
>>>> +{
>>>> +       __raw_writel((u32)val, dws->regs + offset);
>
> dw_writel(dws, offset, val);
>

Yes, I'll make these two changes - at least the write change. Based on 
feedback from your suggestion below, the dw_readw32 may be removed.

>>>> +}
>>>> +
>>>
>>> So, does simple
>>> dws->readw = dw_readl;
>>> dws->writew = dw_writel;
>>>
>>> work for you?
>>>
>>
>> Yes, but I get the macro conflict shown above and "assignment from
>> incompatible pointer type" warnings. If I use the dws->read_w and
>> dws->write_w names, I get the incompatible pointer type warnings but it
>> works.
>>
>> Thanks for reviewing.
>
> Okay, I guess there are two variants:
> a) replace u16 by u32 in existing functions;
> b) introduce new ones like you did.
>
> If no other opinions I think we better go b), but see above comments.
>
> And one more thing. If dw_readw() works for maybe we leave them as is for now?
>

Yes, I just need the 32 bit write. I was trying to remain consistent but 
I agree that only changing only writes would minimize the changes.

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

  parent reply	other threads:[~2015-03-09 19:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-06 23:46 [RFC/PATCHv2 0/3] spi: spi-dw: Select 16b or 32b register access tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
     [not found] ` <1425685594-26595-1-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-06 23:46   ` [RFC/PATCHv2 1/3] spi: dw-spi: Single Register read to clear IRQs tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2015-03-07 19:46     ` Andy Shevchenko
2015-03-09 18:43     ` Mark Brown
2015-03-06 23:46   ` [RFC/PATCHv2 2/3] dt-binding: spi: spi-dw: Select 16b or 32b access for Designware SPI tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2015-03-07 19:58     ` Andy Shevchenko
2015-03-09 18:11       ` Thor Thayer
     [not found]         ` <54FDE250.3050705-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-09 18:19           ` Mark Brown
     [not found]             ` <20150309181936.GU28806-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-03-09 18:25               ` Thor Thayer
2015-03-06 23:46   ` [RFC/PATCHv2 3/3] spi: dw-spi: Pointers select 16b vs. 32b DesignWare access tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
     [not found]     ` <1425685594-26595-4-git-send-email-tthayer-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-07 19:52       ` Andy Shevchenko
2015-03-09 18:01         ` Thor Thayer
     [not found]           ` <54FDDFE6.8010109-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-09 18:54             ` Andy Shevchenko
     [not found]               ` <CAHp75Vf6dgobzZyJxu8eiqGgC7FRrwLCmyMf5Agk6S3jHDj4bw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-09 19:47                 ` Thor Thayer [this message]
2015-03-09 20:02                   ` Andy Shevchenko
     [not found]                     ` <CAHp75VcmNOaiyRNLFzQT7nKS6piZzpYSoS785J86rKtNXx6KNg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-10 20:34                       ` Thor Thayer
2015-03-10 20:40                         ` Mark Brown
     [not found]                         ` <54FF556A.3020408-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-10 20:44                           ` Andy Shevchenko
2015-03-10 22:22                             ` Thor Thayer
     [not found]                               ` <54FF6E91.1010704-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
2015-03-11 10:27                                 ` Andy Shevchenko

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=54FDF8BB.4050202@opensource.altera.com \
    --to=tthayer-yzvpicuk2abmcg4ihk0kfoh6mc4mb0vx@public.gmane.org \
    --cc=andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=axel.lin-8E1dMatC8ynQT0dZR+AlfA@public.gmane.org \
    --cc=baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org \
    --cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dinguyen-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org \
    --cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
    --cc=jg1.han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=jkosina-AlSwsSmVLrQ@public.gmane.org \
    --cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=tthayer.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 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).