On 9 October 2014 19:20, Daniel Vetter wrote:
> On Wed, Oct 8, 2014 at 6:00 PM, Jerome Glisse wrote:
>>
>> struct radeon_ioctl {
>> u32 version;
>> u32 size;
>> };
>
> How is this any different from just another ioctl multiplexer and why
> can't we just add a new version
Hi Linus,
This is the main git pull for the drm, I pretty much froze major pulls at
-rc5/6 time, and haven't had much fallout, so will probably continue doing
that.
Lots of changes all over, big internal header cleanup to make it clear drm
features are legacy things and what are things that
hives/dri-devel/attachments/20141014/cc334c31/attachment.html>
Hi,
So I've been hacking on mutter and the gnome pieces for tiling, and
I've at least fixed mutter locally so maximise windows works and the
heads are in the right order.
Now I've strung all the pieces together using a single KMS property
that X.org propogates, and mutter picks up and propagates
ere is a special case (Tahiti) that we should be addressing
identified by the comment that we are not?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/020c7e98/attachment.html>
Alex,
Please pull these patches through Radeon,
Thanks,
Thomas
On 10/13/2014 08:22 PM, Alex Deucher wrote:
> On Thu, Oct 9, 2014 at 2:02 AM, Michel D?nzer wrote:
>> From: Michel D?nzer
>>
>> The radeon driver uses placement range restrictions for several reasons,
>> in particular to make
On 12.10.2014 05:24, Greg KH wrote:
> On Sat, Oct 11, 2014 at 08:31:49PM +0200, Daniel Vetter wrote:
>> On Fri, Oct 10, 2014 at 05:59:19PM +0900, Michel D?nzer wrote:
>>> On 10.10.2014 17:51, Alan Swanson wrote:
On Fri, 2014-10-10 at 12:20 +0900, Michel D?nzer wrote:
> On 09.10.2014
On 14.10.2014 00:39, Alex Deucher wrote:
> On Wed, Oct 8, 2014 at 4:41 PM, Andrey Germakovski
> wrote:
>> FirePro W600 does not work with more than 4 monitors,
>>
>>
>>
>> After 5th monitor attached X acting very slow.
>>
>>
>>
>> Or if I call drmModeSetCrtc function 5 times one time for each of
f it's too much for asking
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/3867ddf6/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83731
--- Comment #3 from Giancarlo Formicuccia
---
No runpm=0 doesn't help.
I read from your comments on 6c7bccea390853bdec5b76fe31fc50f3b36f75d5 that the
initialization order changed, and it's possibly related to my problem.
FWIW, (last time I
On 10/13/2014 12:16 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> Currently the mipi_dsi_dcs_write() function requires the DCS command
> byte to be embedded within the write buffer whereas mipi_dsi_dcs_read()
> has a separate parameter. Make them more symmetrical by adding an extra
>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/b25ff593/attachment.html>
-
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/dd75d63b/attachment-0001.html>
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/62fb5e0f/attachment.html>
On 10/13/2014 12:16 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> Implement generic read and write commands. Selection of the proper data
> type for packets is done automatically based on the number of parameters
> or payload length.
>
> Signed-off-by: Thierry Reding
> ---
>
> + * @len: size of receive buffer
> > *
> > - * Function returns number of read bytes or error code.
> > + * Return: The number of bytes read or a negative error code on failure.
> > */
> > ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 cmd, void *data,
> > size_t len)
> > {
> > - const struct mipi_dsi_host_ops *ops = dsi->host->ops;
> > struct mipi_dsi_msg msg = {
> > .channel = dsi->channel,
> > .type = MIPI_DSI_DCS_READ,
> > @@ -260,13 +351,13 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device
> > *dsi, u8 cmd, void *data,
> > .rx_len = len
> > };
> >
> > - if (!ops || !ops->transfer)
> > + if (!dsi->host->ops || !dsi->host->ops->transfer)
> > return -ENOSYS;
> >
> > if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
> > msg.flags = MIPI_DSI_MSG_USE_LPM;
> >
> > - return ops->transfer(dsi->host, );
> > + return dsi->host->ops->transfer(dsi->host, );
>
> Again, why multiple evaluations of dsi->host->ops vs single one?
I've undone that change for consistency.
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/acd1bb13/attachment.sig>
r)
> return -NOSYS;
>
> if (dsi->mode_flags & MIPI_DSI_MODE_LPM)
> msg.flags = MIPI_DSI_MSG_USE_LPM;
>
>
> return ops->transfer(dsi->host, msg);
> }
Good idea. It'd be slightly better if we could check for valid ops
earlier, but I don't think it's really worth it. I'll add a helper that
performs these common checks and rebase the other patches on top of it.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/172e72a6/attachment-0001.sig>
preference, that's all.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/fd74bbf8/attachment.sig>
n);
> > + } else {
> > + tx =
> > + size = 1;
> > + }
>
> Contents of this conditional is incompatible with the current API.
> mipi_dsi_msg.tx_buf contains only data and mipi_dsi_msg.tx_len contains
> lenght of this data. Now you try to embed leng
follow-on patch cleaning this up as you see fit.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/cf8a741f/attachment.sig>
} else {
> > + msg.tx_buf = payload;
> > + msg.tx_len = size;
> > + }
>
> Another API breakage, commented already in response to 1st patch.
Can you elaborate? How can this be API breakage if it's a new API being
introduced?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/716151f5/attachment.sig>
On 10/14/2014 11:44 AM, Thierry Reding wrote:
> On Tue, Oct 14, 2014 at 10:00:32AM +0200, Andrzej Hajda wrote:
>> On 10/13/2014 12:16 PM, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> Currently the mipi_dsi_dcs_write() function requires the DCS command
>>> byte to be embedded within the
function is used.
Then it introduces a new function that behaves the same but uses a
different signature that takes the DCS command byte as an explicit
parameter instead of embedding the DCS command byte into the "payload"
buffer.
I don't understand why you think we're changing anything fundamental
here.
> >> And of course changing API would require also changing current users of
> >> the API.
> > There's a single user of this function and this patch switches it over
> > to the compatibility function mipi_dsi_dcs_write_buffer().
>
> Mostly panels are users of these functions and these functions uses
> transfer callback internally. If we allow different semantic for
> transfer msg
> we will end up with panels cooperating only with specific dsi hosts.
> I do not think it is good direction.
That's not at all the intention. Both functions are supposed to keep
working the same way. mipi_dsi_dcs_write_buffer() becomes what was
previously called mipi_dsi_dcs_write() and mipi_dsi_dcs_write() is a
new helper that concatenates a command byte with payload and passes
it into mipi_dsi_dcs_write_buffer().
So if you find that mipi_dsi_dcs_write_buffer() now does the wrong thing
and breaks the s6e8aa0 panel, please point out what exactly is going
wrong so that I can fix it.
> >> But in the first place it would be good to know why do you want to
> >> change the API? What are benefits of this solution?
> > I've already explained this elsewhere.
>
> Where? I remember only one discussion where you claimed this is better
> solution
> for you [1], but without explanation.
I explained this in an earlier reply to you in this thread.
> Do you have patches/repo for tegra with transfer callback implemented
> with this semantic?
> Maybe looking at the code will be helpful.
I posted these patches for review to dri-devel yesterday, so they should
be available there. If you prefer patchwork, see:
https://patchwork.kernel.org/patch/5075161/
And look for tegra_dsi_host_transfer().
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/7b862ef3/attachment.sig>
On 10/14/2014 11:44 AM, Thierry Reding wrote:
> On Tue, Oct 14, 2014 at 10:00:32AM +0200, Andrzej Hajda wrote:
>> On 10/13/2014 12:16 PM, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> Currently the mipi_dsi_dcs_write() function requires the DCS command
>>> byte to be embedded within the
--- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/9c707566/attachment.sig>
On 10/14/2014 12:57 PM, Thierry Reding wrote:
> On Tue, Oct 14, 2014 at 12:38:15PM +0200, Andrzej Hajda wrote:
>> On 10/14/2014 11:44 AM, Thierry Reding wrote:
>>> On Tue, Oct 14, 2014 at 10:00:32AM +0200, Andrzej Hajda wrote:
On 10/13/2014 12:16 PM, Thierry Reding wrote:
> From: Thierry
nt semantics, but that's the whole
> >>> point of it. The else branch here is to optimize for the case where a
> >>> command has no payload. In that case there is no need for allocating an
> >>> extra buffer, since the command byte is the only data transferred.
> >> If this is the whole point of it why patch description says nothing
> >> about it?
> > I thought the patch description said this. What do you think needs to be
> > added?
>
> In short, that new API assumes that transfer callback must interpret
> write buffer
> differently than before :) Ie that sometimes at the beginning of the buffer
> there will be additional bytes.
Right, we never defined exactly which part of code would take which data
and into what data it would be transformed. That obviously breaks as
soon as two implementations make different assumptions. =)
I'm glad we noticed the disconnect this early, where it's still pretty
easy to fix.
> >> It has nothing to do with helpers symmetry, this is serious API change.
> > No, it's not. It replaces an existing API, mipi_dsi_dcs_write() with a
> > different one, mipi_dsi_dcs_write_buffer() and converts the one call
> > site where the function is used.
> >
> > Then it introduces a new function that behaves the same but uses a
> > different signature that takes the DCS command byte as an explicit
> > parameter instead of embedding the DCS command byte into the "payload"
> > buffer.
> >
> > I don't understand why you think we're changing anything fundamental
> > here.
> >
> >>>> And of course changing API would require also changing current users of
> >>>> the API.
> >>> There's a single user of this function and this patch switches it over
> >>> to the compatibility function mipi_dsi_dcs_write_buffer().
> >> Mostly panels are users of these functions and these functions uses
> >> transfer callback internally. If we allow different semantic for
> >> transfer msg
> >> we will end up with panels cooperating only with specific dsi hosts.
> >> I do not think it is good direction.
> > That's not at all the intention. Both functions are supposed to keep
> > working the same way. mipi_dsi_dcs_write_buffer() becomes what was
> > previously called mipi_dsi_dcs_write() and mipi_dsi_dcs_write() is a
> > new helper that concatenates a command byte with payload and passes
> > it into mipi_dsi_dcs_write_buffer().
> >
> > So if you find that mipi_dsi_dcs_write_buffer() now does the wrong thing
> > and breaks the s6e8aa0 panel, please point out what exactly is going
> > wrong so that I can fix it.
>
> The only wrong thing is that s6e8aa0 cannot work with tegra host
> and lq101r1sx01 cannot work with Exynos. Not big deal at the moment
> but clearly bad design. I guess there is non-zero chance that we will have
> a panel which should cooperate with both dsi hosts.
Agreed. The set of bytes transferred to the DSI host should be
rigorously defined to make sure they all end up sending the same
commands to the panels.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/503bcdb9/attachment.sig>
all that's what the kernel is, an abstraction between hardware and
userspace.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/3933d55d/attachment.sig>
(msg->tx_len > 2) {
xfer.tx_payload = >tx_buf[2];
xfer.tx_len = msg->tx_len - 2;
}
And it can probably be even more reduced if the now unneeded .data or
.tx_payload fields are removed.
Thierry
-- next part --
A non-text att
ment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/245b6d8c/attachment-0001.sig>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/61ddefaf/attachment.html>
On Tue, Oct 14, 2014 at 2:29 AM, Michel D?nzer wrote:
> On 14.10.2014 00:39, Alex Deucher wrote:
>>
>> On Wed, Oct 8, 2014 at 4:41 PM, Andrey Germakovski
>> wrote:
>>>
>>> FirePro W600 does not work with more than 4 monitors,
>>>
>>>
>>>
>>> After 5th monitor attached X acting very slow.
>>>
n the wild.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/2ed67f8d/attachment.html>
On Mon, 13 Oct 2014, Yao Cheng wrote:
> Setup following resources during i915_driver_load:
> 1. create a child platform and resource
> 2. allocate a new IRQ line and irq chip
> 3. set up IRQ mask/unmask callbacks
> vxd392 driver (if installed) will bind itself to the
> platform device and create
On 10/14/2014 01:29 PM, Thierry Reding wrote:
> On Tue, Oct 14, 2014 at 01:25:44PM +0200, Andrzej Hajda wrote:
>> On 10/14/2014 12:57 PM, Thierry Reding wrote:
>>> On Tue, Oct 14, 2014 at 12:38:15PM +0200, Andrzej Hajda wrote:
On 10/14/2014 11:44 AM, Thierry Reding wrote:
> On Tue, Oct
Hi Laura,
On 13 October 2014 13:42, Laura Abbott wrote:
> On 10/10/2014 1:07 PM, Sumit Semwal wrote:
>>
>> Hi,
>>
>> Why:
>>
>> While sharing buffers using dma-buf, currently there's no mechanism to
>> let
>> devices share their memory access constraints with each other to allow for
>>
Hi Greg, Daniel!
On 12 October 2014 00:10, Daniel Vetter wrote:
> On Fri, Oct 10, 2014 at 04:09:00PM -0700, Greg Kroah-Hartman wrote:
>> On Sat, Oct 11, 2014 at 01:37:56AM +0530, Sumit Semwal wrote:
>> > Devices sharing buffers using dma-buf could benefit from sharing their
>> > constraints via
Hi Laura,
On 13 October 2014 14:05, Laura Abbott wrote:
> On 10/10/2014 1:07 PM, Sumit Semwal wrote:
>>
>> Devices sharing buffers using dma-buf could benefit from sharing their
>> constraints via struct device, and dma-buf framework would manage the
>> common constraints for all attached
; + if (len > 1) {
> >>>>>>> + tx[offset++] = ((1 + len) >> 0) & 0xff;
> >>>>>>> + tx[offset++] = ((1 + len) >> 8) & 0xff;
> >>>>>>> + }
> >>>>>>> +
> >>>>>>> + /* write the DCS command byte followed by the payload */
> >>>>>>> + tx[offset++] = cmd;
> >>>>>>> + memcpy(tx + offset, data, len);
> >>>>>>> + } else {
> >>>>>>> + tx =
> >>>>>>> + size = 1;
> >>>>>>> + }
> >>>>>> Contents of this conditional is incompatible with the current API.
> >>>>>> mipi_dsi_msg.tx_buf contains only data and mipi_dsi_msg.tx_len contains
> >>>>>> lenght of this data. Now you try to embed length of data into tx_buf
> >>>>>> and
> >>>>>> this breaks the API.
> >>>>> Huh? Of course the new API has different semantics, but that's the whole
> >>>>> point of it. The else branch here is to optimize for the case where a
> >>>>> command has no payload. In that case there is no need for allocating an
> >>>>> extra buffer, since the command byte is the only data transferred.
> >>>> If this is the whole point of it why patch description says nothing
> >>>> about it?
> >>> I thought the patch description said this. What do you think needs to be
> >>> added?
> >> In short, that new API assumes that transfer callback must interpret
> >> write buffer
> >> differently than before :) Ie that sometimes at the beginning of the buffer
> >> there will be additional bytes.
> > Right, we never defined exactly which part of code would take which data
> > and into what data it would be transformed. That obviously breaks as
> > soon as two implementations make different assumptions. =)
>
> In previous version of this patch [1] you have made different assumption,
> and in the discussion you were clearly aware of the current implementation,
> so your reaction here surprises me little bit. Maybe some misunderstanding.
> Anyway I am glad we are now both aware of the problem.
>
> [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/110647
It's possible I didn't realize the full complexity of the problem at the
time. To summarize, I think the helpers in the core should do as much
work as they possibly can, so that drivers don't have to duplicate the
same over and over again. That is, the DCS helpers that are under
discussion here should create a buffer that reflects the packet that is
to be sent to the DSI peripheral, including the specific layout of the
header. So a struct mipi_dsi_msg contains the following information:
- .channel + .type make up the DI (Data ID) field in the packet
header
for short packets:
- .tx_buf[0] and .tx_buf[1] correspond to Data 0 and Data 1
fields in the packet header (both of these are only present if
.tx_len is larger than 0 and 1, and default to 0 otherwise)
for long packets:
- .tx_buf[0] and .tx_buf[1] correspond to the word count
- .tx_buf[2..] represent the payload (word count - 2 bytes)
That's pretty much what section 8.4 General Packet Structure of the DSI
specification describes. This intentionally leaves out the header ECC
and 16-bit packet footer (checksum). These are typically implemented in
hardware, and if they aren't we can provide helpers that compute them
based on the header, and the payload in .tx_buf. That way all the packet
composition defined in the specification is handled by common code and a
driver only needs to have the hardware-specific knowledge, namely where
the various pieces need to be written in order to transmit them as
desired.
Does that make sense?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/428e4bd9/attachment-0001.sig>
On Mon, Oct 13, 2014 at 6:21 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Implement ganged mode support for the Tegra DSI driver. The DSI host
> controller to gang up with is specified via a phandle in the device tree
> and the resolved DSI host controller used for the programming of the
On Tue, Oct 14, 2014 at 4:53 AM, Thierry Reding
wrote:
> On Mon, Oct 13, 2014 at 08:15:00PM +0800, Yao Cheng wrote:
>> drm/ipvr is a new GEM driver for baytrail's vxd392, which accelerates VP8
>> video decoding.
>> The driver name "ipvr" means the PowerVR's IP wrapped by Intel. In the
>>
On Wed, Sep 24, 2014 at 4:45 PM, Oded Gabbay wrote:
> To support HSA on KV, we need to limit the number of vmids and pipes
> that are available for radeon's use with KV.
>
> This patch reserves VMIDs 8-15 for amdkfd (so radeon can only use VMIDs
> 0-7) and also makes radeon thinks that KV has
On Wed, Sep 24, 2014 at 4:45 PM, Oded Gabbay wrote:
> amdkfd should set interrupts for pipes 1-7.
>
> Signed-off-by: Oded Gabbay
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/cik.c | 71
> +---
> 1 file changed, 1 insertion(+), 70
On Wed, Sep 24, 2014 at 4:45 PM, Oded Gabbay wrote:
> radeon and amdkfd share the doorbell aperture.
> radeon sets it up, takes the doorbells required for its own rings
> and reports the setup to amdkfd.
> radeon reserved doorbells are at the start of the doorbell aperture.
>
> Signed-off-by:
On Wed, Sep 24, 2014 at 4:45 PM, Oded Gabbay wrote:
> Implementing a lock for selecting and accessing shader engines and arrays.
> This lock will make sure that radeon and amdkfd are not colliding when
> accessing shader engines and arrays with GRBM_GFX_INDEX register.
>
> Signed-off-by: Oded
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/10402131/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141014/ca1030dd/attachment.html>
13.10.2014, 21:50, "Alex Deucher" :
> On Fri, Oct 10, 2014 at 12:00 PM, Alex Deucher
> wrote:
>> ?I think I'd prefer to just switch the test to use gart memory since
>> ?this code is shared by different asics thay may not all implement hdp
>> ?flush the same way. ?We can just reserve a couple of
Hi,
the first patch reduces the sparse warnings and the second removes unused
code. I think the patches could be applied independently but both act on
the dpm files, so here's why the series.
I'm not sure about the patches but at least I experiment with
git send-email..
Please don't kill me
remove some dpm functions never called, mostly xxx_dpm_reset_asic
functions. Here the list:
* btc_dpm_reset_asic
* ci_power_control_set_level
* ci_set_boot_state
* ci_dpm_power_control_set_level
* ci_dpm_reset_asic
* cypress_dpm_reset_asic
* kv_dpm_reset_asic
* ni_dpm_reset_asic
*
include radeon_asic.h header file in the various xxx_dpm.c files
to reduce sparse false positive warnings. Not so great patch
in itself, but reducing warning count from 391 to 258 may help
to see real problems..
Signed-off-by: Michele Curti
---
drivers/gpu/drm/radeon/btc_dpm.c | 1 +
51 matches
Mail list logo
