All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Tony Lindgren <tony@atomide.com>, Suman Anna <s-anna@ti.com>,
	Grazvydas Ignotas <notasas@gmail.com>
Cc: Tero Kristo <t-kristo@ti.com>, Keerthy <j-keerthy@ti.com>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/9] Some OMAP2+ legacy hwmod data cleanup
Date: Tue, 13 Feb 2018 17:55:10 +0100	[thread overview]
Message-ID: <96379836-1E9F-4E90-B6E4-31DB544A18BB@goldelico.com> (raw)
In-Reply-To: <20180213154622.GE6364@atomide.com>

Hi,

> Am 13.02.2018 um 16:46 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * Suman Anna <s-anna@ti.com> [180213 01:33]:
>> Hi Tony,
>> 
>> The following series cleans up some legacy dev_attr data associated
>> with OMAP DMTimer, I2C, McBSP, McSPI and GPIO modules and removes
>> roughly ~500 lines. Patches are based on v4.16-rc1. I have build tested
>> for both omap2plus and omap1 defconfigs, and booted on a few OMAP4+
>> boards that I have on my desk.
> 
> Hey that's great :)
> 
>> Here is the patch summary:
>> 1. First two patches fixes header inclusion in omap-dmaengine.h and
>>    hsmmc-omap.h as I am getting build errors on subsequent patches when
>>    I removed some of the platform_data header files.
>> 2. Patches 3 through 7 remove the .dev_attr data for the above modules
>>    from various hwmod data files and some macros from McSPI & McBSP
>>    platform data header files
>> 3. Patch 8 moves the plat-omap/include/plat/i2c.h into mach-omap1
>>    folder as there is no common i2c code in plat-omap folder anymore.
>> 4. Last patch is a minor cleanup of gpio headers from couple of files.
>> 
>> Some important notes/comments:
>> - The DMTimer patch cleanup will conflict with Keerthy's current dmtimer->
>>   clocksource series, but ideally he wouldn't need to convert the plat/dmtimer.h
>>   into a clocksource header with the removal of the plat/dmtimer.h inclusion
>>   from the hwmod data files.
> 
> OK. It seems that we should do the clean up first if it just means
> leaving out unused header files.
> 
>> - I found some gaps w.r.t DMTimers on DM814x/DM816x platforms, and haven't
>>   fixed them. Both seems to have DMTimer1 through 8, but only DMTimers 1, 2
>>   and 3 are defined in dm814x.dtsi, while dm816x.dtsi is missing DMTimer8.
>>   DMTimer3 hwmod is not in the dm814x hwmod list, while DMTimer8 is left out
>>   altogther. The timer capabilities are also different between the hwmod
>>   data files (lists always-on) which is missing from corresponding dts files.
>>   Not sure which one is correct.
> 
> OK we should fix them. The capabilities can be seen by looking at
> the hardware and clockdomains. The always-on timers are of sysc
> type 1 (ti,sysc-omap2-timer) and in a always on power domain. The
> others are of sysc type 2 (ti,sysc-omap4-timer). We should get
> warnings for those from ti,sysc driver eventually if they don't
> match :)
> 
>> This leaves the hsmmc-omap and omap-dma pieces still using the .dev_attr. The
>> former is only used by one OMAP3 board, so can be cleaned up if we limit the
>> init code just for that one board.
> 
> I think Nikolaus had patches coming for removing the last user
> of mmc pdata?

Well, the idea was to convert the wl1251 driver to DT (like e.g. wl183x)
and get rid of the pdata. But I didn't find any time to work on this,
especially since the driver itself is broken for a while (I think up
to 4.11 the wl1251 was found and working, after that it wasn't working
and after 4.14 or so it wasn't even found any more). Probably some
simple things, but as usual time consuming to dig into.

> 
> I think all we need to do is have pandora_wl1251_init_card
> initialized in the MMC driver based on a compatible value..

Yes, looks so.

BR and thanks,
Nikolaus

WARNING: multiple messages have this Message-ID (diff)
From: hns@goldelico.com (H. Nikolaus Schaller)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/9] Some OMAP2+ legacy hwmod data cleanup
Date: Tue, 13 Feb 2018 17:55:10 +0100	[thread overview]
Message-ID: <96379836-1E9F-4E90-B6E4-31DB544A18BB@goldelico.com> (raw)
In-Reply-To: <20180213154622.GE6364@atomide.com>

Hi,

> Am 13.02.2018 um 16:46 schrieb Tony Lindgren <tony@atomide.com>:
> 
> * Suman Anna <s-anna@ti.com> [180213 01:33]:
>> Hi Tony,
>> 
>> The following series cleans up some legacy dev_attr data associated
>> with OMAP DMTimer, I2C, McBSP, McSPI and GPIO modules and removes
>> roughly ~500 lines. Patches are based on v4.16-rc1. I have build tested
>> for both omap2plus and omap1 defconfigs, and booted on a few OMAP4+
>> boards that I have on my desk.
> 
> Hey that's great :)
> 
>> Here is the patch summary:
>> 1. First two patches fixes header inclusion in omap-dmaengine.h and
>>    hsmmc-omap.h as I am getting build errors on subsequent patches when
>>    I removed some of the platform_data header files.
>> 2. Patches 3 through 7 remove the .dev_attr data for the above modules
>>    from various hwmod data files and some macros from McSPI & McBSP
>>    platform data header files
>> 3. Patch 8 moves the plat-omap/include/plat/i2c.h into mach-omap1
>>    folder as there is no common i2c code in plat-omap folder anymore.
>> 4. Last patch is a minor cleanup of gpio headers from couple of files.
>> 
>> Some important notes/comments:
>> - The DMTimer patch cleanup will conflict with Keerthy's current dmtimer->
>>   clocksource series, but ideally he wouldn't need to convert the plat/dmtimer.h
>>   into a clocksource header with the removal of the plat/dmtimer.h inclusion
>>   from the hwmod data files.
> 
> OK. It seems that we should do the clean up first if it just means
> leaving out unused header files.
> 
>> - I found some gaps w.r.t DMTimers on DM814x/DM816x platforms, and haven't
>>   fixed them. Both seems to have DMTimer1 through 8, but only DMTimers 1, 2
>>   and 3 are defined in dm814x.dtsi, while dm816x.dtsi is missing DMTimer8.
>>   DMTimer3 hwmod is not in the dm814x hwmod list, while DMTimer8 is left out
>>   altogther. The timer capabilities are also different between the hwmod
>>   data files (lists always-on) which is missing from corresponding dts files.
>>   Not sure which one is correct.
> 
> OK we should fix them. The capabilities can be seen by looking at
> the hardware and clockdomains. The always-on timers are of sysc
> type 1 (ti,sysc-omap2-timer) and in a always on power domain. The
> others are of sysc type 2 (ti,sysc-omap4-timer). We should get
> warnings for those from ti,sysc driver eventually if they don't
> match :)
> 
>> This leaves the hsmmc-omap and omap-dma pieces still using the .dev_attr. The
>> former is only used by one OMAP3 board, so can be cleaned up if we limit the
>> init code just for that one board.
> 
> I think Nikolaus had patches coming for removing the last user
> of mmc pdata?

Well, the idea was to convert the wl1251 driver to DT (like e.g. wl183x)
and get rid of the pdata. But I didn't find any time to work on this,
especially since the driver itself is broken for a while (I think up
to 4.11 the wl1251 was found and working, after that it wasn't working
and after 4.14 or so it wasn't even found any more). Probably some
simple things, but as usual time consuming to dig into.

> 
> I think all we need to do is have pandora_wl1251_init_card
> initialized in the MMC driver based on a compatible value..

Yes, looks so.

BR and thanks,
Nikolaus

  reply	other threads:[~2018-02-13 16:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-13  1:32 [PATCH 0/9] Some OMAP2+ legacy hwmod data cleanup Suman Anna
2018-02-13  1:32 ` Suman Anna
2018-02-13  1:32 ` [PATCH 1/9] dmaengine: omap-dma: include header for bool type Suman Anna
2018-02-13  1:32   ` Suman Anna
2018-02-14 18:07   ` Tony Lindgren
2018-02-14 18:07     ` Tony Lindgren
2018-02-14 18:22     ` Suman Anna
2018-02-14 18:22       ` Suman Anna
2018-02-13  1:32 ` [PATCH 2/9] mmc: hsmmc_omap: include types.h and provide header inclusion guard Suman Anna
2018-02-13  1:32   ` Suman Anna
2018-02-14 17:50   ` Tony Lindgren
2018-02-14 17:50     ` Tony Lindgren
2018-02-13  1:32 ` [PATCH 3/9] ARM: OMAP2+: Cleanup omap_gpio_dev_attr usage Suman Anna
2018-02-13  1:32   ` Suman Anna
2018-02-13  1:32 ` [PATCH 4/9] ARM: OMAP2+: Cleanup omap_i2c_dev_attr usage Suman Anna
2018-02-13  1:32   ` Suman Anna
2018-02-13  1:32 ` [PATCH 5/9] ARM: OMAP2+: Cleanup omap_timer_capability_dev_attr usage Suman Anna
2018-02-13  1:32   ` Suman Anna
2018-02-13  1:32 ` [PATCH 6/9] ARM: OMAP2+: Cleanup omap2_spi_dev_attr and other legacy data Suman Anna
2018-02-13  1:32   ` Suman Anna
2018-02-13  1:32 ` [PATCH 7/9] ARM: OMAP2+: Cleanup omap_mcbsp_dev_attr " Suman Anna
2018-02-13  1:32   ` Suman Anna
2018-02-13  1:32 ` [PATCH 8/9] ARM: OMAP: Move plat/i2c.h into mach-omap1 folder Suman Anna
2018-02-13  1:32   ` Suman Anna
2018-02-13  1:32 ` [PATCH 9/9] ARM: OMAP2+: Remove unused gpio header file references Suman Anna
2018-02-13  1:32   ` Suman Anna
2018-02-13 15:46 ` [PATCH 0/9] Some OMAP2+ legacy hwmod data cleanup Tony Lindgren
2018-02-13 15:46   ` Tony Lindgren
2018-02-13 16:55   ` H. Nikolaus Schaller [this message]
2018-02-13 16:55     ` H. Nikolaus Schaller

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=96379836-1E9F-4E90-B6E4-31DB544A18BB@goldelico.com \
    --to=hns@goldelico.com \
    --cc=j-keerthy@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=notasas@gmail.com \
    --cc=s-anna@ti.com \
    --cc=t-kristo@ti.com \
    --cc=tony@atomide.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.