All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jimmy RUBIN <jimmy.rubin@stericsson.com>
Cc: "linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Dan JOHANSSON <dan.johansson@stericsson.com>,
	Linus WALLEIJ <linus.walleij@stericsson.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 01/10] MCDE: Add hardware abstraction layer
Date: Tue, 16 Nov 2010 17:12:31 +0100	[thread overview]
Message-ID: <201011161712.31703.arnd@arndb.de> (raw)
In-Reply-To: <F45880696056844FA6A73F415B568C6953604E7D94@EXDCVYMBSTM006.EQ1STM.local>

On Tuesday 16 November 2010, Jimmy RUBIN wrote:
> 
> > Even static variables like these can cause problems. Ideally all of
> > these
> > are referenced through a driver private data structure that is passed
> > around
> > with the device. This way you can trivially support multiple devices if
> > that ever becomes necessary.
> 
> What is the general opinion about singleton drivers?
> Both global and static variables could be fixed if the driver is redesigned to support multiple devices.

I don't know if there is a general rule. The reason why I don't like to have
device specific data spread across global variables is that it messes up
my mental model of the code.

Every device in Linux "normally" is set up by a bus probe (or as a hack,
a platform device instance) and given to a device driver, which then
allocates a private data structure that describes what the driver but
not the bus knows about this device. That data structure typically also
contains the locks for all in-memory and physical state of the device.
If you deviate from this model, you make it harder for reviewers and
other developers to understand what is going on.

> > > +static inline u32 dsi_rreg(int i, u32 reg)
> > > +{
> > > +	return readl(dsiio[i] + reg);
> > > +}
> > > +static inline void dsi_wreg(int i, u32 reg, u32 val)
> > > +{
> > > +	writel(val, dsiio[i] + reg);
> > > +}
> > 
> > dsiio is not marked __iomem, so there is something wrong here.
> > Moreover, why do you need two indexes? If you have multiple identical
> > "dsiio" structures, maybe each of them should just be a device by
> > itself?
> We will add __iomem.
> Each dsi link (dsiio[x]) is tightly coupled with mcde and it feels that they should not be a device of their own.
> We feel that it would be to many devices doing little.

Ok.

> > This looks a bit like you actually have multiple interrupt lines
> > multiplexed
> > through a private interrupt controller. Have you considered making this
> > controller
> > a separate device to multiplex the interrupt numbers?
> 
> MCDE contains several pipelines, each of them can generate interrupts.
> Since each interrupt comes from the same device there is no need for
> separate devices for interrupt controller.

Right, so this one and the one above is really a question of how to describe
a pipeline

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 01/10] MCDE: Add hardware abstraction layer
Date: Tue, 16 Nov 2010 16:12:31 +0000	[thread overview]
Message-ID: <201011161712.31703.arnd@arndb.de> (raw)
In-Reply-To: <F45880696056844FA6A73F415B568C6953604E7D94@EXDCVYMBSTM006.EQ1STM.local>

On Tuesday 16 November 2010, Jimmy RUBIN wrote:
> 
> > Even static variables like these can cause problems. Ideally all of
> > these
> > are referenced through a driver private data structure that is passed
> > around
> > with the device. This way you can trivially support multiple devices if
> > that ever becomes necessary.
> 
> What is the general opinion about singleton drivers?
> Both global and static variables could be fixed if the driver is redesigned to support multiple devices.

I don't know if there is a general rule. The reason why I don't like to have
device specific data spread across global variables is that it messes up
my mental model of the code.

Every device in Linux "normally" is set up by a bus probe (or as a hack,
a platform device instance) and given to a device driver, which then
allocates a private data structure that describes what the driver but
not the bus knows about this device. That data structure typically also
contains the locks for all in-memory and physical state of the device.
If you deviate from this model, you make it harder for reviewers and
other developers to understand what is going on.

> > > +static inline u32 dsi_rreg(int i, u32 reg)
> > > +{
> > > +	return readl(dsiio[i] + reg);
> > > +}
> > > +static inline void dsi_wreg(int i, u32 reg, u32 val)
> > > +{
> > > +	writel(val, dsiio[i] + reg);
> > > +}
> > 
> > dsiio is not marked __iomem, so there is something wrong here.
> > Moreover, why do you need two indexes? If you have multiple identical
> > "dsiio" structures, maybe each of them should just be a device by
> > itself?
> We will add __iomem.
> Each dsi link (dsiio[x]) is tightly coupled with mcde and it feels that they should not be a device of their own.
> We feel that it would be to many devices doing little.

Ok.

> > This looks a bit like you actually have multiple interrupt lines
> > multiplexed
> > through a private interrupt controller. Have you considered making this
> > controller
> > a separate device to multiplex the interrupt numbers?
> 
> MCDE contains several pipelines, each of them can generate interrupts.
> Since each interrupt comes from the same device there is no need for
> separate devices for interrupt controller.

Right, so this one and the one above is really a question of how to describe
a pipeline

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/10] MCDE: Add hardware abstraction layer
Date: Tue, 16 Nov 2010 17:12:31 +0100	[thread overview]
Message-ID: <201011161712.31703.arnd@arndb.de> (raw)
In-Reply-To: <F45880696056844FA6A73F415B568C6953604E7D94@EXDCVYMBSTM006.EQ1STM.local>

On Tuesday 16 November 2010, Jimmy RUBIN wrote:
> 
> > Even static variables like these can cause problems. Ideally all of
> > these
> > are referenced through a driver private data structure that is passed
> > around
> > with the device. This way you can trivially support multiple devices if
> > that ever becomes necessary.
> 
> What is the general opinion about singleton drivers?
> Both global and static variables could be fixed if the driver is redesigned to support multiple devices.

I don't know if there is a general rule. The reason why I don't like to have
device specific data spread across global variables is that it messes up
my mental model of the code.

Every device in Linux "normally" is set up by a bus probe (or as a hack,
a platform device instance) and given to a device driver, which then
allocates a private data structure that describes what the driver but
not the bus knows about this device. That data structure typically also
contains the locks for all in-memory and physical state of the device.
If you deviate from this model, you make it harder for reviewers and
other developers to understand what is going on.

> > > +static inline u32 dsi_rreg(int i, u32 reg)
> > > +{
> > > +	return readl(dsiio[i] + reg);
> > > +}
> > > +static inline void dsi_wreg(int i, u32 reg, u32 val)
> > > +{
> > > +	writel(val, dsiio[i] + reg);
> > > +}
> > 
> > dsiio is not marked __iomem, so there is something wrong here.
> > Moreover, why do you need two indexes? If you have multiple identical
> > "dsiio" structures, maybe each of them should just be a device by
> > itself?
> We will add __iomem.
> Each dsi link (dsiio[x]) is tightly coupled with mcde and it feels that they should not be a device of their own.
> We feel that it would be to many devices doing little.

Ok.

> > This looks a bit like you actually have multiple interrupt lines
> > multiplexed
> > through a private interrupt controller. Have you considered making this
> > controller
> > a separate device to multiplex the interrupt numbers?
> 
> MCDE contains several pipelines, each of them can generate interrupts.
> Since each interrupt comes from the same device there is no need for
> separate devices for interrupt controller.

Right, so this one and the one above is really a question of how to describe
a pipeline

	Arnd

  reply	other threads:[~2010-11-16 16:11 UTC|newest]

Thread overview: 130+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-10 12:04 [PATCH 00/10] MCDE: Add frame buffer device driver Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` Jimmy Rubin
2010-11-10 12:04 ` [PATCH 01/10] MCDE: Add hardware abstraction layer Jimmy Rubin
2010-11-10 12:04   ` Jimmy Rubin
2010-11-10 12:04   ` Jimmy Rubin
2010-11-10 12:04   ` [PATCH 02/10] MCDE: Add configuration registers Jimmy Rubin
2010-11-10 12:04     ` Jimmy Rubin
2010-11-10 12:04     ` Jimmy Rubin
2010-11-10 12:04     ` [PATCH 03/10] MCDE: Add pixel processing registers Jimmy Rubin
2010-11-10 12:04       ` Jimmy Rubin
2010-11-10 12:04       ` Jimmy Rubin
2010-11-10 12:04       ` [PATCH 04/10] MCDE: Add formatter registers Jimmy Rubin
2010-11-10 12:04         ` Jimmy Rubin
2010-11-10 12:04         ` Jimmy Rubin
2010-11-10 12:04         ` [PATCH 05/10] MCDE: Add dsi link registers Jimmy Rubin
2010-11-10 12:04           ` Jimmy Rubin
2010-11-10 12:04           ` Jimmy Rubin
2010-11-10 12:04           ` [PATCH 06/10] MCDE: Add generic display Jimmy Rubin
2010-11-10 12:04             ` Jimmy Rubin
2010-11-10 12:04             ` Jimmy Rubin
2010-11-10 12:04             ` [PATCH 07/10] MCDE: Add display subsystem framework Jimmy Rubin
2010-11-10 12:04               ` Jimmy Rubin
2010-11-10 12:04               ` Jimmy Rubin
2010-11-10 12:04               ` [PATCH 08/10] MCDE: Add frame buffer device Jimmy Rubin
2010-11-10 12:04                 ` Jimmy Rubin
2010-11-10 12:04                 ` Jimmy Rubin
2010-11-10 12:04                 ` [PATCH 09/10] MCDE: Add build files and bus Jimmy Rubin
2010-11-10 12:04                   ` Jimmy Rubin
2010-11-10 12:04                   ` Jimmy Rubin
2010-11-10 12:04                   ` [PATCH 10/10] ux500: MCDE: Add platform specific data Jimmy Rubin
2010-11-10 12:04                     ` Jimmy Rubin
2010-11-10 12:04                     ` Jimmy Rubin
2010-11-12 16:03                     ` Arnd Bergmann
2010-11-12 16:03                       ` Arnd Bergmann
2010-11-12 16:03                       ` Arnd Bergmann
2010-11-25 11:20                       ` Jimmy RUBIN
2010-11-25 11:20                         ` Jimmy RUBIN
2010-11-12 16:23                   ` [PATCH 09/10] MCDE: Add build files and bus Arnd Bergmann
2010-11-12 16:23                     ` Arnd Bergmann
2010-11-12 16:23                     ` Arnd Bergmann
2010-11-12 16:29                 ` [PATCH 08/10] MCDE: Add frame buffer device Arnd Bergmann
2010-11-12 16:29                   ` Arnd Bergmann
2010-11-12 16:29                   ` Arnd Bergmann
2010-11-25 11:52                   ` Jimmy RUBIN
2010-11-25 11:52                     ` Jimmy RUBIN
2010-11-12 16:38               ` [PATCH 07/10] MCDE: Add display subsystem framework Arnd Bergmann
2010-11-12 16:38                 ` Arnd Bergmann
2010-11-12 16:38                 ` Arnd Bergmann
2010-11-25  7:16                 ` Jimmy RUBIN
2010-11-25  7:16                   ` Jimmy RUBIN
2010-11-12 15:46       ` [PATCH 03/10] MCDE: Add pixel processing registers Arnd Bergmann
2010-11-12 15:46         ` Arnd Bergmann
2010-11-12 15:46         ` Arnd Bergmann
2010-11-12 15:14     ` [PATCH 02/10] MCDE: Add configuration registers Arnd Bergmann
2010-11-12 15:14       ` Arnd Bergmann
2010-11-12 15:14       ` Arnd Bergmann
2010-11-12 15:34       ` Russell King - ARM Linux
2010-11-12 15:34         ` Russell King - ARM Linux
2010-11-12 15:34         ` Russell King - ARM Linux
2010-11-15 14:25         ` Arnd Bergmann
2010-11-15 14:25           ` Arnd Bergmann
2010-11-15 14:25           ` Arnd Bergmann
2010-11-15 14:59           ` Russell King - ARM Linux
2010-11-15 14:59             ` Russell King - ARM Linux
2010-11-15 14:59             ` Russell King - ARM Linux
2010-11-15 18:24             ` Geert Uytterhoeven
2010-11-15 18:24               ` Geert Uytterhoeven
2010-11-15 18:24               ` Geert Uytterhoeven
2010-11-25 11:30       ` Jimmy RUBIN
2010-11-25 11:30         ` Jimmy RUBIN
2010-11-25 16:21         ` Arnd Bergmann
2010-11-25 16:21           ` Arnd Bergmann
2010-11-10 17:14   ` [PATCH 01/10] MCDE: Add hardware abstraction layer Joe Perches
2010-11-10 17:14     ` Joe Perches
2010-11-10 17:14     ` Joe Perches
2010-11-15  9:52     ` Jimmy RUBIN
2010-11-15  9:52       ` Jimmy RUBIN
2010-11-15  9:52       ` Jimmy RUBIN
2010-11-15 16:30       ` Joe Perches
2010-11-15 16:30         ` Joe Perches
2010-11-15 16:30         ` Joe Perches
2010-11-12 15:43   ` Arnd Bergmann
2010-11-12 15:43     ` Arnd Bergmann
2010-11-12 15:43     ` Arnd Bergmann
2010-11-16 15:29     ` Jimmy RUBIN
2010-11-16 15:29       ` Jimmy RUBIN
2010-11-16 15:29       ` Jimmy RUBIN
2010-11-16 16:12       ` Arnd Bergmann [this message]
2010-11-16 16:12         ` Arnd Bergmann
2010-11-16 16:12         ` Arnd Bergmann
2010-11-16 16:16         ` Arnd Bergmann
2010-11-16 16:16           ` Arnd Bergmann
2010-11-16 16:16           ` Arnd Bergmann
2010-11-16 19:46       ` Joe Perches
2010-11-16 19:46         ` Joe Perches
2010-11-16 19:46         ` Joe Perches
2010-11-17  9:55         ` Arnd Bergmann
2010-11-17  9:55           ` Arnd Bergmann
2010-11-17  9:55           ` Arnd Bergmann
2010-11-17 16:01           ` Joe Perches
2010-11-17 16:01             ` Joe Perches
2010-11-17 16:01             ` Joe Perches
2010-11-10 14:42 ` [PATCH 00/10] MCDE: Add frame buffer device driver Alex Deucher
2010-11-10 14:42   ` Alex Deucher
2010-11-10 14:42   ` Alex Deucher
2010-11-12 13:18   ` Jimmy RUBIN
2010-11-12 13:18     ` Jimmy RUBIN
2010-11-12 13:18     ` Jimmy RUBIN
2010-11-12 15:52     ` Alex Deucher
2010-11-12 15:52       ` Alex Deucher
2010-11-12 15:52       ` Alex Deucher
2010-11-12 16:46       ` Marcus LORENTZON
2010-11-12 16:46         ` Marcus LORENTZON
2010-11-12 16:46         ` Marcus LORENTZON
2010-11-12 17:22         ` Alex Deucher
2010-11-12 17:22           ` Alex Deucher
2010-11-12 17:22           ` Alex Deucher
2010-11-15 11:05           ` Michel Dänzer
2010-11-15 11:05             ` Michel Dänzer
2010-11-15 11:05             ` Michel Dänzer
2010-11-13 11:54         ` Hans Verkuil
2010-11-13 11:54           ` Hans Verkuil
2010-11-13 11:54           ` Hans Verkuil
2010-11-13 17:26           ` Marcus LORENTZON
2010-11-13 17:26             ` Marcus LORENTZON
2010-11-13 17:26             ` Marcus LORENTZON
2010-11-13 17:57             ` Hans Verkuil
2010-11-13 17:57               ` Hans Verkuil
2010-11-13 17:57               ` Hans Verkuil

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=201011161712.31703.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=dan.johansson@stericsson.com \
    --cc=jimmy.rubin@stericsson.com \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.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.