All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Cousson, Benoit" <b-cousson@ti.com>
To: "Valkeinen, Tomi" <tomi.valkeinen@ti.com>
Cc: "Taneja, Archit" <archit@ti.com>,
	"Semwal, Sumit" <sumit.semwal@ti.com>,
	"paul@pwsan.com" <paul@pwsan.com>,
	"Hilman, Kevin" <khilman@ti.com>,
	"Hiremath, Vaibhav" <hvaibhav@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Guruswamy, Senthilvadivu" <svadivu@ti.com>
Subject: Re: [PATCH v10 05/18] OMAP2,3 DSS2 Change driver name to omap_display
Date: Mon, 28 Feb 2011 15:00:44 +0100	[thread overview]
Message-ID: <4D6BAA8C.2020203@ti.com> (raw)
In-Reply-To: <1298895026.9809.27.camel@deskari>

On 2/28/2011 1:10 PM, Valkeinen, Tomi wrote:
> On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
>> Hi Tomi,
>>
>> On 2/28/2011 8:19 AM, Valkeinen, Tomi wrote:
>>> On Mon, 2011-02-28 at 01:09 -0600, Taneja, Archit wrote:
>>>> Hi,
>>>>
>>>> On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote:
>>>>> On Thu, 2011-02-24 at 03:27 -0600, Tomi Valkeinen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, 2011-01-24 at 11:51 +0530, ext Sumit Semwal wrote:
>>>>>>> From: Senthilvadivu Guruswamy<svadivu@ti.com>
>>>>>>>
>>>>>>> Change the driver name from omapdss to omap_display as the driver takes care of
>>>>>>> the display devices ie number of panels, type of panels available in the
>>>>>>> platform.  Change the device name in the board files and 2420,2430,3xxx clock
>>>>>>> files from omapdss to omap_display to match the driver name.
>>>>>>
>>>>>> I just realized that changing the driver name will break all scripts and
>>>>>> applications using omapdss sysfs files.
>>>>>>
>>>>>> How does this sound:
>>>>>>
>>>>>> Let's leave the omapdss device name as it is. It represents a "super"
>>>>>> device, containing the dss sysfs files and upper level dss management.
>>
>> This is the case for all the drivers migrated to omap_device anyway due
>> to the change in the top level hierarchy. Everything is below
>> platform/omap now.
>
> The HW module drivers are under platform/omap/, but omapdss is in
> platform/. Do you mean that omapdss should also be under platform/omap/?

This is because you are probably not using omap_device yet. is should 
happen when you will change your platform_device to be omap_device.

> The reason I'm unwilling to change omapdss name, or location, is that
> omapdss directory contains lots of DSS configuration files, used by
> scripts and programs.

Is that used for debug only?

>> That's why we are using that opportunity to clean and provide a
>> consistent naming for all devices.
>>
>>>>>> Name the HW module platform drivers as: omapdss_dss, omapdss_venc,
>>>>>> omapdss_dispc, etc. This would indicate them to be clearly parts of DSS,
>>>>>> and would also prevent any possible name conflict if there would happen
>>>>>> to be a, say, "dsi" block in some other HW component.
>>
>> Cannot you use a device hierarchy then to do that?
>>    omap_dss/core
>>    omap_dss/dsi
>>    omap_dss/venc
>>
>> This is moreover the way the HW is done.
>
> Hmm, how would that work? The devices are platform devices, and they
> have a unique global name, which is used to match the driver for the
> device.

Practically, I don't really know :-) Please see the reply to Russell.

>>>>> Any comments on this?
>>>>
>>>> I also think we need to stick to the older name, "omapdss_dss" sounds a
>>>> bit confusing, and I think one of the previous versions had something
>>>> like "dss_dss" in it and it wasn't approved. Does something like
>>>> "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?
>>>
>>> It is confusing, but so is the hardware naming =). There is a DSS module
>>> inside the omap display subsystem. That's why I would like to name it
>>> "dss", not "core", so it's clear it refers to this DSS module.
>>>
>>> "dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly
>>> better in the sense that it doesn't repeat the same "dss", and there is
>>> an "omapdss" device, which acts like "manager" for these module devices.
>>> But yes, I wouldn't call it perfect either.
>>>
>>> "omapdss_dss_core" is one option. But then again, TRM doesn't speak of
>>> "core".
>>
>> We should not maintain silly names just because they are in the TRM, we
>> should just fix the TRM. This is exactly what we are going to do for
>> most HW names we introduced in OMAP4.
>>
>> So if we all agree that this name will avoid confusion and is much
>> better than the current one, we can change it right now with a comment
>> to explain the change and give the pointer to the current TRM naming.
>
> True. But I don't think there's a huge difference with omapdss_dss or
> omapdss_core.

You're right, at the end it is just a name. We are just trying to clean 
a little bit the current devices name mess. So the convention we are 
trying to enforce is to name omap devices omap_XXX.

> The name is used in only a few places inside the kernel, and never from
> userspace, so we can change that also later.
>
> The main issue I had was changing the omapdss device name, which would
> break the userspace.

That's why we'd better break it properly today once and for all :-)
At least when you will migrate to omap_device.

Benoit


WARNING: multiple messages have this Message-ID (diff)
From: b-cousson@ti.com (Cousson, Benoit)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v10 05/18] OMAP2, 3 DSS2 Change driver name to omap_display
Date: Mon, 28 Feb 2011 15:00:44 +0100	[thread overview]
Message-ID: <4D6BAA8C.2020203@ti.com> (raw)
In-Reply-To: <1298895026.9809.27.camel@deskari>

On 2/28/2011 1:10 PM, Valkeinen, Tomi wrote:
> On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
>> Hi Tomi,
>>
>> On 2/28/2011 8:19 AM, Valkeinen, Tomi wrote:
>>> On Mon, 2011-02-28 at 01:09 -0600, Taneja, Archit wrote:
>>>> Hi,
>>>>
>>>> On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote:
>>>>> On Thu, 2011-02-24 at 03:27 -0600, Tomi Valkeinen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, 2011-01-24 at 11:51 +0530, ext Sumit Semwal wrote:
>>>>>>> From: Senthilvadivu Guruswamy<svadivu@ti.com>
>>>>>>>
>>>>>>> Change the driver name from omapdss to omap_display as the driver takes care of
>>>>>>> the display devices ie number of panels, type of panels available in the
>>>>>>> platform.  Change the device name in the board files and 2420,2430,3xxx clock
>>>>>>> files from omapdss to omap_display to match the driver name.
>>>>>>
>>>>>> I just realized that changing the driver name will break all scripts and
>>>>>> applications using omapdss sysfs files.
>>>>>>
>>>>>> How does this sound:
>>>>>>
>>>>>> Let's leave the omapdss device name as it is. It represents a "super"
>>>>>> device, containing the dss sysfs files and upper level dss management.
>>
>> This is the case for all the drivers migrated to omap_device anyway due
>> to the change in the top level hierarchy. Everything is below
>> platform/omap now.
>
> The HW module drivers are under platform/omap/, but omapdss is in
> platform/. Do you mean that omapdss should also be under platform/omap/?

This is because you are probably not using omap_device yet. is should 
happen when you will change your platform_device to be omap_device.

> The reason I'm unwilling to change omapdss name, or location, is that
> omapdss directory contains lots of DSS configuration files, used by
> scripts and programs.

Is that used for debug only?

>> That's why we are using that opportunity to clean and provide a
>> consistent naming for all devices.
>>
>>>>>> Name the HW module platform drivers as: omapdss_dss, omapdss_venc,
>>>>>> omapdss_dispc, etc. This would indicate them to be clearly parts of DSS,
>>>>>> and would also prevent any possible name conflict if there would happen
>>>>>> to be a, say, "dsi" block in some other HW component.
>>
>> Cannot you use a device hierarchy then to do that?
>>    omap_dss/core
>>    omap_dss/dsi
>>    omap_dss/venc
>>
>> This is moreover the way the HW is done.
>
> Hmm, how would that work? The devices are platform devices, and they
> have a unique global name, which is used to match the driver for the
> device.

Practically, I don't really know :-) Please see the reply to Russell.

>>>>> Any comments on this?
>>>>
>>>> I also think we need to stick to the older name, "omapdss_dss" sounds a
>>>> bit confusing, and I think one of the previous versions had something
>>>> like "dss_dss" in it and it wasn't approved. Does something like
>>>> "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?
>>>
>>> It is confusing, but so is the hardware naming =). There is a DSS module
>>> inside the omap display subsystem. That's why I would like to name it
>>> "dss", not "core", so it's clear it refers to this DSS module.
>>>
>>> "dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly
>>> better in the sense that it doesn't repeat the same "dss", and there is
>>> an "omapdss" device, which acts like "manager" for these module devices.
>>> But yes, I wouldn't call it perfect either.
>>>
>>> "omapdss_dss_core" is one option. But then again, TRM doesn't speak of
>>> "core".
>>
>> We should not maintain silly names just because they are in the TRM, we
>> should just fix the TRM. This is exactly what we are going to do for
>> most HW names we introduced in OMAP4.
>>
>> So if we all agree that this name will avoid confusion and is much
>> better than the current one, we can change it right now with a comment
>> to explain the change and give the pointer to the current TRM naming.
>
> True. But I don't think there's a huge difference with omapdss_dss or
> omapdss_core.

You're right, at the end it is just a name. We are just trying to clean 
a little bit the current devices name mess. So the convention we are 
trying to enforce is to name omap devices omap_XXX.

> The name is used in only a few places inside the kernel, and never from
> userspace, so we can change that also later.
>
> The main issue I had was changing the omapdss device name, which would
> break the userspace.

That's why we'd better break it properly today once and for all :-)
At least when you will migrate to omap_device.

Benoit

  parent reply	other threads:[~2011-02-28 14:00 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-24  6:21 [PATCH v10 00/18] OMAP2,3: hwmod DSS Adaptation Sumit Semwal
2011-01-24  6:21 ` Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 01/18] OMAP2,3: DSS2: remove forced clk-disable from omap_dss_remove Sumit Semwal
2011-01-24  6:21   ` [PATCH v10 01/18] OMAP2, 3: " Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 02/18] OMAP2420: hwmod data: add DSS DISPC RFBI VENC Sumit Semwal
2011-01-24  6:21   ` Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 03/18] OMAP2430: " Sumit Semwal
2011-01-24  6:21   ` Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 04/18] OMAP3: hwmod data: add DSS DISPC RFBI DSI VENC Sumit Semwal
2011-01-24  6:21   ` Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 05/18] OMAP2,3 DSS2 Change driver name to omap_display Sumit Semwal
2011-01-24  6:21   ` Sumit Semwal
2011-02-24  9:27   ` Tomi Valkeinen
2011-02-24  9:27     ` Tomi Valkeinen
2011-02-28  6:53     ` Tomi Valkeinen
2011-02-28  6:53       ` Tomi Valkeinen
2011-02-28  7:09       ` archit taneja
2011-02-28  7:09         ` [PATCH v10 05/18] OMAP2, 3 " archit taneja
2011-02-28  7:19         ` [PATCH v10 05/18] OMAP2,3 " Tomi Valkeinen
2011-02-28  7:19           ` Tomi Valkeinen
2011-02-28  7:27           ` archit taneja
2011-02-28  7:27             ` [PATCH v10 05/18] OMAP2, 3 " archit taneja
2011-02-28  8:16             ` [PATCH v10 05/18] OMAP2,3 " Semwal, Sumit
2011-02-28  8:16               ` [PATCH v10 05/18] OMAP2, 3 " Semwal, Sumit
2011-02-28  8:29               ` [PATCH v10 05/18] OMAP2,3 " Tomi Valkeinen
2011-02-28  8:29                 ` Tomi Valkeinen
2011-02-28 11:36           ` Cousson, Benoit
2011-02-28 11:36             ` [PATCH v10 05/18] OMAP2, 3 " Cousson, Benoit
2011-02-28 12:10             ` [PATCH v10 05/18] OMAP2,3 " Tomi Valkeinen
2011-02-28 12:10               ` Tomi Valkeinen
2011-02-28 12:13               ` Russell King - ARM Linux
2011-02-28 12:13                 ` Russell King - ARM Linux
2011-02-28 13:38                 ` Cousson, Benoit
2011-02-28 13:38                   ` [PATCH v10 05/18] OMAP2, 3 " Cousson, Benoit
2011-02-28 14:06                   ` [PATCH v10 05/18] OMAP2,3 " Russell King - ARM Linux
2011-02-28 14:06                     ` Russell King - ARM Linux
2011-02-28 14:55                     ` Cousson, Benoit
2011-02-28 14:55                       ` [PATCH v10 05/18] OMAP2, 3 " Cousson, Benoit
2011-02-28 14:00               ` Cousson, Benoit [this message]
2011-02-28 14:00                 ` Cousson, Benoit
2011-02-28 14:57                 ` [PATCH v10 05/18] OMAP2,3 " Tomi Valkeinen
2011-02-28 14:57                   ` Tomi Valkeinen
2011-03-01 10:18                   ` Cousson, Benoit
2011-03-01 10:18                     ` [PATCH v10 05/18] OMAP2, 3 " Cousson, Benoit
2011-01-24  6:21 ` [PATCH v10 06/18] OMAP2,3 DSS2 Use Regulator init with driver name Sumit Semwal
2011-01-24  6:21   ` Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 07/18] OMAP2,3: DSS2: Create new file display.c for central dss driver registration Sumit Semwal
2011-01-24  6:21   ` [PATCH v10 07/18] OMAP2, 3: " Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 08/18] OMAP2,3: DSS2: board files: replace platform_device_register with omap_display_init() Sumit Semwal
2011-01-24  6:21   ` [PATCH v10 08/18] OMAP2, 3: " Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 09/18] OMAP2,3: DSS2: Build omap_device for each DSS HWIP Sumit Semwal
2011-01-24  6:21   ` Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 10/18] OMAP2,3: DSS2: DSS: create platform_driver, move init,exit to driver Sumit Semwal
2011-01-24  6:21   ` [PATCH v10 10/18] OMAP2, 3: DSS2: DSS: create platform_driver, move init, exit " Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 11/18] OMAP2,3: DSS2: Move clocks from core driver to dss driver Sumit Semwal
2011-01-24  6:21   ` [PATCH v10 11/18] OMAP2, 3: " Sumit Semwal
2011-01-24  6:21 ` [PATCH v10 12/18] OMAP2,3: DSS2: RFBI: create platform_driver, move init,exit to driver Sumit Semwal
2011-01-24  6:21   ` [PATCH v10 12/18] OMAP2, 3: DSS2: RFBI: create platform_driver, move init, exit " Sumit Semwal
2011-01-24  6:22 ` [PATCH v10 13/18] OMAP2,3: DSS2: DISPC: create platform_driver, move init,exit " Sumit Semwal
2011-01-24  6:22   ` [PATCH v10 13/18] OMAP2, 3: DSS2: DISPC: create platform_driver, move init, exit " Sumit Semwal
2011-01-24  6:22 ` [PATCH v10 14/18] OMAP2,3: DSS2: VENC: create platform_driver, move init,exit " Sumit Semwal
2011-01-24  6:22   ` [PATCH v10 14/18] OMAP2, 3: DSS2: VENC: create platform_driver, move init, exit " Sumit Semwal
2011-01-24  6:22 ` [PATCH v10 15/18] OMAP2,3: DSS2: DSI: create platform_driver, move init,exit " Sumit Semwal
2011-01-24  6:22   ` [PATCH v10 15/18] OMAP2, 3: DSS2: DSI: create platform_driver, move init, exit " Sumit Semwal
2011-01-24  6:22 ` [PATCH v10 16/18] OMAP2,3: DSS2: replace printk with dev_dbg in init Sumit Semwal
2011-01-24  6:22   ` Sumit Semwal
2011-01-24  6:22 ` [PATCH v10 17/18] OMAP2,3: DSS2: Use platform device to get baseaddr Sumit Semwal
2011-01-24  6:22   ` Sumit Semwal
2011-01-24  6:22 ` [PATCH v10 18/18] OMAP2,3: DSS2: Get DSS IRQ from platform device Sumit Semwal
2011-01-24  6:22   ` Sumit Semwal
2011-01-27 12:49   ` Raghuveer Murthy
2011-01-27 12:49     ` [PATCH v10 18/18] OMAP2, 3: " Raghuveer Murthy
2011-01-27 12:59     ` Russell King - ARM Linux
2011-01-27 12:59       ` Russell King - ARM Linux
2011-01-27 13:04       ` Raghuveer Murthy
2011-01-27 13:04         ` Raghuveer Murthy
2011-01-27 15:23         ` Semwal, Sumit
2011-01-27 15:23           ` Semwal, Sumit
2011-02-14 14:09   ` [PATCH v10 18/18] OMAP2,3: " Tomi Valkeinen
2011-02-14 14:09     ` Tomi Valkeinen
2011-02-14 18:35     ` Semwal, Sumit
2011-02-14 18:35       ` [PATCH v10 18/18] OMAP2, 3: " Semwal, Sumit
2011-01-24 21:57 ` [PATCH v10 00/18] OMAP2,3: hwmod DSS Adaptation Kevin Hilman
2011-01-24 21:57   ` Kevin Hilman
2011-01-25 17:03   ` Tony Lindgren
2011-01-25 17:03     ` Tony Lindgren
2011-01-28 12:01     ` Tomi Valkeinen
2011-01-28 12:01       ` Tomi Valkeinen

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=4D6BAA8C.2020203@ti.com \
    --to=b-cousson@ti.com \
    --cc=archit@ti.com \
    --cc=hvaibhav@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=sumit.semwal@ti.com \
    --cc=svadivu@ti.com \
    --cc=tomi.valkeinen@ti.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.