All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emil Velikov <emil.l.velikov@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Liviu Dudau <Liviu.Dudau@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-rockchip <linux-rockchip@lists.infradead.org>,
	LAKML <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.
Date: Mon, 19 Oct 2015 16:04:27 +0100	[thread overview]
Message-ID: <CACvgo53e-zFcDawbPNaOB8sQcNH-sFDmYi5sXRhp5z6T9oC2=A@mail.gmail.com> (raw)
In-Reply-To: <20151019145027.GF32532@n2100.arm.linux.org.uk>

On 19 October 2015 at 15:50, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 04:42:25PM +0200, Daniel Vetter wrote:
>> On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote:
>> > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
>> > > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote:
>> > > > Please don't move this into here, it's completely inappropriate.  Just
>> > > > because something makes use of this does not mean they only support
>> > > > 32-bit DMA.  Besides, this has nothing to do with whether or not it's
>> > > > OF-based or not.
>> > >
>> > > Understood. My thinking process was that component-based drivers are all
>> > > OF-enabled (how else do you make use of the framework?) and 32-bit DMA is
>> > > present in 2 out of 3 drivers that are converted, so it looks to be common
>> > > enough that adding it to armada would not hurt. It was all done in the name of
>> > > collecting common code in a single function.
>> >
>> > Which is an utterly crap reason.
>> >
>> > It's also not appropriate.  I'm really not sure why you think that moving
>> > this here would in any way be appropriate - from my point of view, the
>> > mere proposal is utterly insane.
>> >
>> > The "container" device does not do any DMA, so it's inappropriate for
>> > it to have DMA masks set or negotiated on it.  So, actually, no one
>> > should be setting the DMA mask for their container device.  It's wrong.
>>
>> I think (and my opinion doesn't carry as much wheight here on dri-devel
>> than intel-gfx) the above is over the top bashing of a new contributor to
>> drm who really seems trying to do right. I think that's unecessary,
>> especially since you follow up with the reasonable reply below.
>
> It's justified because it took _two_ messages to get the point across.
> The first one asking nicely didn't make the necessary impact.
>
Unlike Daniel, I carry little to no weight here, yet bashing on people
if they don't get things correct the first time is inconsiderable.
We are people - we can misread/misinterpret things, have a headache
and/or just a bad day. If that makes you angry/annoyed, please don't
reply straight away, but give it a few hours/day for the emotions to
settle.

Thanks
Emil

WARNING: multiple messages have this Message-ID (diff)
From: Emil Velikov <emil.l.velikov@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Liviu Dudau <Liviu.Dudau@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-rockchip <linux-rockchip@lists.infradead.org>,
	LAKML <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.
Date: Mon, 19 Oct 2015 16:04:27 +0100	[thread overview]
Message-ID: <CACvgo53e-zFcDawbPNaOB8sQcNH-sFDmYi5sXRhp5z6T9oC2=A@mail.gmail.com> (raw)
In-Reply-To: <20151019145027.GF32532@n2100.arm.linux.org.uk>

On 19 October 2015 at 15:50, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 04:42:25PM +0200, Daniel Vetter wrote:
>> On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote:
>> > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
>> > > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote:
>> > > > Please don't move this into here, it's completely inappropriate.  Just
>> > > > because something makes use of this does not mean they only support
>> > > > 32-bit DMA.  Besides, this has nothing to do with whether or not it's
>> > > > OF-based or not.
>> > >
>> > > Understood. My thinking process was that component-based drivers are all
>> > > OF-enabled (how else do you make use of the framework?) and 32-bit DMA is
>> > > present in 2 out of 3 drivers that are converted, so it looks to be common
>> > > enough that adding it to armada would not hurt. It was all done in the name of
>> > > collecting common code in a single function.
>> >
>> > Which is an utterly crap reason.
>> >
>> > It's also not appropriate.  I'm really not sure why you think that moving
>> > this here would in any way be appropriate - from my point of view, the
>> > mere proposal is utterly insane.
>> >
>> > The "container" device does not do any DMA, so it's inappropriate for
>> > it to have DMA masks set or negotiated on it.  So, actually, no one
>> > should be setting the DMA mask for their container device.  It's wrong.
>>
>> I think (and my opinion doesn't carry as much wheight here on dri-devel
>> than intel-gfx) the above is over the top bashing of a new contributor to
>> drm who really seems trying to do right. I think that's unecessary,
>> especially since you follow up with the reasonable reply below.
>
> It's justified because it took _two_ messages to get the point across.
> The first one asking nicely didn't make the necessary impact.
>
Unlike Daniel, I carry little to no weight here, yet bashing on people
if they don't get things correct the first time is inconsiderable.
We are people - we can misread/misinterpret things, have a headache
and/or just a bad day. If that makes you angry/annoyed, please don't
reply straight away, but give it a few hours/day for the emotions to
settle.

Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: emil.l.velikov@gmail.com (Emil Velikov)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 1/4] drm: Introduce generic probe function for component based masters.
Date: Mon, 19 Oct 2015 16:04:27 +0100	[thread overview]
Message-ID: <CACvgo53e-zFcDawbPNaOB8sQcNH-sFDmYi5sXRhp5z6T9oC2=A@mail.gmail.com> (raw)
In-Reply-To: <20151019145027.GF32532@n2100.arm.linux.org.uk>

On 19 October 2015 at 15:50, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 04:42:25PM +0200, Daniel Vetter wrote:
>> On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote:
>> > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
>> > > On Mon, Oct 19, 2015 at 01:25:37PM +0100, Russell King - ARM Linux wrote:
>> > > > Please don't move this into here, it's completely inappropriate.  Just
>> > > > because something makes use of this does not mean they only support
>> > > > 32-bit DMA.  Besides, this has nothing to do with whether or not it's
>> > > > OF-based or not.
>> > >
>> > > Understood. My thinking process was that component-based drivers are all
>> > > OF-enabled (how else do you make use of the framework?) and 32-bit DMA is
>> > > present in 2 out of 3 drivers that are converted, so it looks to be common
>> > > enough that adding it to armada would not hurt. It was all done in the name of
>> > > collecting common code in a single function.
>> >
>> > Which is an utterly crap reason.
>> >
>> > It's also not appropriate.  I'm really not sure why you think that moving
>> > this here would in any way be appropriate - from my point of view, the
>> > mere proposal is utterly insane.
>> >
>> > The "container" device does not do any DMA, so it's inappropriate for
>> > it to have DMA masks set or negotiated on it.  So, actually, no one
>> > should be setting the DMA mask for their container device.  It's wrong.
>>
>> I think (and my opinion doesn't carry as much wheight here on dri-devel
>> than intel-gfx) the above is over the top bashing of a new contributor to
>> drm who really seems trying to do right. I think that's unecessary,
>> especially since you follow up with the reasonable reply below.
>
> It's justified because it took _two_ messages to get the point across.
> The first one asking nicely didn't make the necessary impact.
>
Unlike Daniel, I carry little to no weight here, yet bashing on people
if they don't get things correct the first time is inconsiderable.
We are people - we can misread/misinterpret things, have a headache
and/or just a bad day. If that makes you angry/annoyed, please don't
reply straight away, but give it a few hours/day for the emotions to
settle.

Thanks
Emil

  reply	other threads:[~2015-10-19 15:04 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-19 12:21 [RFC PATCH v2 0/4] drm: Cleanup probe function for component based masters Liviu Dudau
2015-10-19 12:21 ` Liviu Dudau
2015-10-19 12:21 ` Liviu Dudau
2015-10-19 12:21 ` [RFC PATCH v2 1/4] drm: Introduce generic " Liviu Dudau
2015-10-19 12:21   ` Liviu Dudau
2015-10-19 12:21   ` Liviu Dudau
2015-10-19 12:25   ` Russell King - ARM Linux
2015-10-19 12:25     ` Russell King - ARM Linux
2015-10-19 12:25     ` Russell King - ARM Linux
2015-10-19 13:02     ` Liviu Dudau
2015-10-19 13:02       ` Liviu Dudau
2015-10-19 13:26       ` Russell King - ARM Linux
2015-10-19 13:26         ` Russell King - ARM Linux
2015-10-19 13:26         ` Russell King - ARM Linux
2015-10-19 13:32         ` Liviu Dudau
2015-10-19 13:32           ` Liviu Dudau
2015-10-19 13:32           ` Liviu Dudau
2015-10-19 13:38           ` Russell King - ARM Linux
2015-10-19 13:38             ` Russell King - ARM Linux
2015-10-19 13:38             ` Russell King - ARM Linux
2015-10-19 14:42         ` Daniel Vetter
2015-10-19 14:42           ` Daniel Vetter
2015-10-19 14:42           ` Daniel Vetter
2015-10-19 14:50           ` Russell King - ARM Linux
2015-10-19 14:50             ` Russell King - ARM Linux
2015-10-19 14:50             ` Russell King - ARM Linux
2015-10-19 15:04             ` Emil Velikov [this message]
2015-10-19 15:04               ` Emil Velikov
2015-10-19 15:04               ` Emil Velikov
2015-10-19 15:21               ` Russell King - ARM Linux
2015-10-19 15:21                 ` Russell King - ARM Linux
2015-10-19 15:07             ` Liviu Dudau
2015-10-19 15:07               ` Liviu Dudau
2015-10-19 15:07               ` Liviu Dudau
2015-10-19 12:21 ` [RFC PATCH v2 2/4] drm/imx: Convert the probe function to the generic drm_of_component_probe() Liviu Dudau
2015-10-19 12:21   ` Liviu Dudau
2015-10-19 12:21   ` Liviu Dudau
2015-10-19 12:21 ` [RFC PATCH v2 3/4] drm/rockchip: " Liviu Dudau
2015-10-19 12:21   ` Liviu Dudau
2015-10-19 12:21   ` Liviu Dudau
2015-10-19 12:21 ` [RFC PATCH v2 4/4] drm/armada: " Liviu Dudau
2015-10-19 12:21   ` Liviu Dudau
2015-10-19 12:21   ` Liviu Dudau

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='CACvgo53e-zFcDawbPNaOB8sQcNH-sFDmYi5sXRhp5z6T9oC2=A@mail.gmail.com' \
    --to=emil.l.velikov@gmail.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    /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.