From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kevin Hilman <khilman@baylibre.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Michael Turquette <mturquette@baylibre.com>,
Sekhar Nori <nsekhar@ti.com>, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
Russell King <linux@armlinux.org.uk>,
LKML <linux-kernel@vger.kernel.org>,
arm-soc <linux-arm-kernel@lists.infradead.org>,
linux-drm <dri-devel@lists.freedesktop.org>,
linux-devicetree <devicetree@vger.kernel.org>,
Jyri Sarha <jsarha@ti.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
David Airlie <airlied@linux.ie>, Arnd Bergmann <arnd@arndb.de>,
Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
Date: Thu, 20 Oct 2016 21:05:50 +0300 [thread overview]
Message-ID: <1867292.F3aGJTmS2t@avalon> (raw)
In-Reply-To: <7h8ttj6jqo.fsf@baylibre.com>
Hi Kevin,
On Thursday 20 Oct 2016 09:57:51 Kevin Hilman wrote:
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:
> > On Wednesday 19 Oct 2016 10:26:57 Bartosz Golaszewski wrote:
> >> 2016-10-18 22:49 GMT+02:00 Laurent Pinchart:
> >>> On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote:
> >>>> Create the driver for the da8xx System Configuration and implement
> >>>> support for writing to the three Master Priority registers.
> >>>>
> >>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >>
> >> [snip]
> >>
> >>>> +
> >>>> +Documentation:
> >>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> >>>> +
> >>>> +Required properties:
> >>>> +
> >>>> +- compatible: "ti,da850-syscfg"
> >>>
> >>> Don't you need a reg property ?
> >>
> >> Yes, Kevin already pointed that out. I'll add it in v2. Same for [1/3].
> >>
> >>>> +Optional properties:
> >>>> +
> >>>> +The below properties are used to specify the priority of master
> >>>> peripherals.
> >>>> +They must be between 0-7 where 0 is the highest priority and 7 is the
> >>>> lowest.
> >>>> +
> >>>> +- ti,pri-arm-i: ARM_I port priority.
> >>>> +
> >>>> +- ti,pri-arm-d: ARM_D port priority.
> >>>> +
> >>>> +- ti,pri-upp: uPP port priority.
> >>>> +
> >>>> +- ti,pri-sata: SATA port priority.
> >>>> +
> >>>> +- ti,pri-pru0: PRU0 port priority.
> >>>> +
> >>>> +- ti,pri-pru1: PRU1 port priority.
> >>>> +
> >>>> +- ti,pri-edma30tc0: EDMA3_0_TC0 port priority.
> >>>> +
> >>>> +- ti,pri-edma30tc1: EDMA3_0_TC1 port priority.
> >>>> +
> >>>> +- ti,pri-edma31tc0: EDMA3_1_TC0 port priority.
> >>>> +
> >>>> +- ti,pri-vpif-dma-0: VPIF DMA0 port priority.
> >>>> +
> >>>> +- ti,pri-vpif-dma-1: VPIF DMA1 port priority.
> >>>> +
> >>>> +- ti,pri-emac: EMAC port priority.
> >>>> +
> >>>> +- ti,pri-usb0cfg: USB0 CFG port priority.
> >>>> +
> >>>> +- ti,pri-usb0cdma: USB0 CDMA port priority.
> >>>> +
> >>>> +- ti,pri-uhpi: HPI port priority.
> >>>> +
> >>>> +- ti,pri-usb1: USB1 port priority.
> >>>> +
> >>>> +- ti,pri-lcdc: LCDC port priority.
> >>>
> >>> I'm afraid this looks more like system configuration than hardware
> >>> description to me.
> >>
> >> While you're certainly right, this approach is already implemented in
> >> several other memory and bus drivers and it was also suggested by
> >> Sekhar in one of the tilcdc rev1 threads. There's also no real
> >> alternative that I know of.
> >
> > The fact that other drivers get it wrong is no excuse for copying them :-)
>
> What exactly is "wrong" with the way other drivers are doing it?
>
> I'm sure there may be other ideas, and possibly some better ones, but
> that doesn't make it wrong, and doesn't change he fact that the kernel
> has existing drivers SoC-bus-specific system performance knobs like
> this.
It's not the drivers I'm concerned about, but the DT bindings. The proposed DT
binding contains a large number of properties that don't describe the hardware
but contain configuration data. If they're accepted you'll have to carry them
forward forever, while they should be controlled in a more flexible way.
> >>> There was a BoF session about how to support this kind of performance
> >>> knobs at ELCE last week:
> >>> https://openiotelceurope2016.sched.org/event/7rss/bof-linux-device-perf
> >>> ormance-framework-michael-turquette-baylibre :-)
> >>
> >> Unfortunately it was just a discussion about potential approaches -
> >> there's no code yet.
> >
> > Patches are welcome ;-)
>
> Any generic perf framework will have to build on the HW-specifics of
> individual busses, so IMO, the lack of a generic performance
> framework/knobs should not be a reason to block the inclusion of any
> bus-specific knobs.
>
> I guess this ultimately would go though arm-soc, so I've added Arnd &
> Olof to the thread.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2016-10-20 18:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-17 16:30 [PATCH 0/3] ARM: da850: new drivers for better LCDC support Bartosz Golaszewski
2016-10-17 16:30 ` [PATCH 1/3] ARM: memory: da8xx-ddrctl: new driver Bartosz Golaszewski
2016-10-17 16:54 ` Kevin Hilman
2016-10-18 20:45 ` Laurent Pinchart
2016-10-17 16:30 ` [PATCH 2/3] ARM: bus: da8xx-syscfg: " Bartosz Golaszewski
2016-10-17 16:57 ` Kevin Hilman
2016-10-18 20:49 ` Laurent Pinchart
2016-10-19 8:26 ` Bartosz Golaszewski
2016-10-19 8:53 ` Laurent Pinchart
2016-10-20 16:57 ` Kevin Hilman
2016-10-20 18:05 ` Laurent Pinchart [this message]
2016-10-20 19:39 ` Kevin Hilman
2016-10-21 9:25 ` Tomi Valkeinen
2016-10-21 9:53 ` Sekhar Nori
2016-10-21 9:56 ` Tomi Valkeinen
2016-10-17 16:30 ` [PATCH 3/3] ARM: dts: da850: add the syscfg and ddrctl nodes Bartosz Golaszewski
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=1867292.F3aGJTmS2t@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=airlied@linux.ie \
--cc=arnd@arndb.de \
--cc=bgolaszewski@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=frowand.list@gmail.com \
--cc=jsarha@ti.com \
--cc=khilman@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=mturquette@baylibre.com \
--cc=nsekhar@ti.com \
--cc=olof@lixom.net \
--cc=peter.ujfalusi@ti.com \
--cc=robh+dt@kernel.org \
--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 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).