It's completely unused and there's really no reason for this:
- drm_framebuffer structures are invariant after creation, no need for
helpers to manipulate them.
- drm_framebuffer structures should just be embedded (and that's what
all the drivers do).
Stumbled over this since some folks are ap
in the distant
> future. A u32 pad after bo_handle and a 'pointer' to struct
I'm curious what you think we can add to a 3d box.
So this one is fine, no need to align it either I don't think, though I
should confirm that.
Maybe for safety we can pull the other uint3
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150910/cc10ed01/attachment.html>
2015-09-10 18:35 GMT+02:00 Enric Balletbo i Serra :
> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> designed for portable devices.
>
> You can add support to your board with current binding.
>
> Example:
>
> anx7814: anx7814 at 38 {
> compatible
Hi Enric,
On Thursday 10 September 2015 16:11:03 Enric Balletbo Serra wrote:
> 2015-09-09 2:40 GMT+02:00 Rob Herring :
> > On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote:
> >> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> >> designed for portable devices.
> >>
>
At the moment it only supports ANX7814.
The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.
This driver adds initial support and supports HDMI to DP pass-through mode.
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/bridge/Kconfig
The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.
You can add support to your board with current binding.
Example:
anx7814: anx7814 at 38 {
compatible = "analogix,anx7814";
reg = <0x38>;
Analogix Semiconductor develops analog and mixed-signal devices for digital
media and communications interconnect applications.
Signed-off-by: Enric Balletbo i Serra
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi all,
This is the third version with more changes requested by Dan.
The following series add initial support for the Slimport ANX7814 transmitter, a
ultra-low power Full-HD (1080p60) transmitter designed for portable device.
The driver was originally created and based from the work of Junhua X
https://bugzilla.kernel.org/show_bug.cgi?id=88921
Eduard Bloch changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Wed, Aug 05, 2015 at 04:46:38PM +0200, Daniel Vetter wrote:
> If we shut down the crtc we might run into WM consistency checks which
> fail because we haven't yet read out the WM state. So do that before
> we sanitized the state.
>
> This fixes a WARNING in the ilk wm code which assumes that le
Hi,
> > Dave? Looking at the ioctls they are all fine for render nodes, there
> > isn't anything modesetting related in the device-specific ioctls.
> >
> > Correct?
> >
> Unless I've overdone the coffee this time - modesetting is done via
> the card# node, while render via either card# or rende
Hi,
> Just a FYI - Daniel Vetter has a series in flight which deprecates
> DRM_UNLOCKED for KMS drivers.
Thanks for the heads up.
>
> > --- /dev/null
> > +++ b/include/uapi/drm/virtgpu_drm.h
> > @@ -0,0 +1,163 @@
>
> > +
> > +struct drm_virtgpu_3d_box {
> > + uint32_t x, y, z;
> > +
Hi Dave -
Fixes headed for v4.3-rc1, including Maarten's DP MST state checker fix
you requested.
BR,
Jani.
The following changes since commit 6fa2d197936ba0b8936e813d0adecefac160062b:
i915: Set ddi_pll_sel in DP MST path (2015-09-01 12:42:27 +0300)
are available in the git repository at:
On Do, 2015-09-10 at 09:59 +0100, Emil Velikov wrote:
> On 9 September 2015 at 12:42, Gerd Hoffmann wrote:
> > From: Dave Airlie
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
> > drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/d
Hi Rob,
2015-09-09 2:40 GMT+02:00 Rob Herring :
> On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote:
>> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
>> designed for portable devices.
>>
>> You can add support to your board with current binding.
>>
>> Example:
>>
>>
drm_crtc_index(struct drm_crtc *crtc);
> > +extern struct drm_crtc *drm_get_crtc_from_index(struct drm_device *dev,
> > + unsigned int index);
> >
> > /**
> > * drm_crtc_mask - find the mask of a registered CRTC
> > --
> > 1.9.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150910/3f0c0596/attachment-0001.html>
On Do, 2015-09-10 at 09:39 +0100, Emil Velikov wrote:
> Hi Gerd,
>
> On 9 September 2015 at 12:42, Gerd Hoffmann wrote:
> > Add virtio_gpu_queue_ctrl_buffer_nolock function, which does the same as
> > virtio_gpu_queue_ctrl_buffer but does not take the virtqueue lock. The
> > caller must hold the
On 10 September 2015 at 15:52, Gerd Hoffmann wrote:
> Hi,
>
>> > Dave? Looking at the ioctls they are all fine for render nodes, there
>> > isn't anything modesetting related in the device-specific ioctls.
>> >
>> > Correct?
>> >
>> Unless I've overdone the coffee this time - modesetting is don
Op 10-09-15 om 11:51 schreef Daniel Vetter:
> On Tue, Sep 08, 2015 at 03:26:47PM +0200, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> These functions are like drm_modeset_{,un}lock_all(), but they take the
>> lock acquisition context as a parameter rather than storing it in the
>> DRM device
On 10 September 2015 at 15:23, Gerd Hoffmann wrote:
> On Do, 2015-09-10 at 09:59 +0100, Emil Velikov wrote:
>> On 9 September 2015 at 12:42, Gerd Hoffmann wrote:
>> > From: Dave Airlie
>> >
>> > Signed-off-by: Gerd Hoffmann
>> > ---
>> > drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
>> > 1 file
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150910/842c7506/attachment-0001.html>
nts/20150910/5009dc8b/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150910/4637f444/attachment-0001.html>
Hi all,
XDC2015, is less than a week a way! I have posted a tentative schedule
on the wiki[1].
If you are a speaker and have questions about the schedule or want to
request a new time slot, please let me know. I will do my best, but I
may not be able to accommodate everyone's request.
Each pre
On 10 September 2015 at 11:32, Dave Airlie wrote:
>> > --- /dev/null
>> > +++ b/include/uapi/drm/virtgpu_drm.h
>> > @@ -0,0 +1,163 @@
>>
>> > +
>> > +struct drm_virtgpu_3d_box {
>> > + uint32_t x, y, z;
>> > + uint32_t w, h, d;
>> > +};
>> > +
>> There was a similar case (multiple vari
---
drivers/gpu/drm/amd/amdgpu/vi.c | 41 -
1 file changed, 16 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 6e76c7e..015cdae 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gp
On 07/09/15 14:06, Ville Syrjälä wrote:
> On Mon, Sep 07, 2015 at 10:53:06AM +0100, Emil Velikov wrote:
>> As going through the modetest patches for atomic support I've noticed
>> that if we pass NULL for the drmModeAtomicReqPtr argument we'll crash.
>>
>> So let's handle things appropriately if
On Thu, Sep 10, 2015 at 10:07:41AM +0100, Tvrtko Ursulin wrote:
>
> On 09/09/2015 08:06 PM, Daniel Vetter wrote:
> >On Wed, Sep 9, 2015 at 6:36 PM, Tvrtko Ursulin
> > wrote:
> >>I am not even going that far, just talking about last frame stuck on screen.
> >>For me making that easier is a regressi
On Tue, Sep 08, 2015 at 03:26:47PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> These functions are like drm_modeset_{,un}lock_all(), but they take the
> lock acquisition context as a parameter rather than storing it in the
> DRM device's drm_mode_config structure.
>
> Implement drm_m
On Wed, Sep 9, 2015 at 1:21 PM, Emil Velikov
wrote:
> Hello all,
>
> With this series, we add a couple of new functions drm{Get,Free}Device,
> which will be used to query information about the opened device.
>
> To do that some refactoring was done, plus an extra test is added to
> demonstrate ho
On Thu, Sep 10, 2015 at 04:07:16PM +0800, Xinliang Liu wrote:
> On 25 August 2015 at 17:36, Daniel Vetter wrote:
> Hi Daniel,
> Thank you very much for reply. Sorry, I just come back from vacation.
> Very happy that you have a good idea to solve the mess.
> Looking forward to see your patch soon!
On 09/08/2015 03:57 PM, Andrzej Hajda wrote:
> On 09/07/2015 01:46 PM, Archit Taneja wrote:
>> Thierry,
>>
>> On 08/21/2015 11:39 AM, Archit Taneja wrote:
>>>
>>>
>>> On 08/20/2015 05:18 PM, Thierry Reding wrote:
On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:
> Hi Thierry
On 09/10/2015 10:56 AM, Daniel Vetter wrote:
> On Thu, Sep 10, 2015 at 10:07:41AM +0100, Tvrtko Ursulin wrote:
>>
>> On 09/09/2015 08:06 PM, Daniel Vetter wrote:
>>> On Wed, Sep 9, 2015 at 6:36 PM, Tvrtko Ursulin
>>> wrote:
I am not even going that far, just talking about last frame stuck on
On 09/09/2015 08:06 PM, Daniel Vetter wrote:
> On Wed, Sep 9, 2015 at 6:36 PM, Tvrtko Ursulin
> wrote:
>> I am not even going that far, just talking about last frame stuck on screen.
>> For me making that easier is a regression.
>
> So let's look at various systems:
> - super-modern fbdev less sy
On 9 September 2015 at 12:42, Gerd Hoffmann wrote:
> From: Dave Airlie
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> b/drivers/gpu/drm/virtio/virtgpu_
Hello Gert,
On 9 September 2015 at 12:42, Gerd Hoffmann wrote:
> Add the bits needed for opengl rendering support: query
> capabilities, new virtio commands, drm ioctls.
>
> Signed-off-by: Dave Airlie
> Signed-off-by: Gerd Hoffmann
> ---
> +
> +struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTI
Hi Gerd,
On 9 September 2015 at 12:42, Gerd Hoffmann wrote:
> Add virtio_gpu_queue_ctrl_buffer_nolock function, which does the same as
> virtio_gpu_queue_ctrl_buffer but does not take the virtqueue lock. The
> caller must hold the lock instead.
>
The drm subsystem tends to use *_locked and *_unl
imilar to the way an HDMI encoder driver would
> >>>>use an I2C adapter to query EDID. The i2c_client device would be a means
> >>>>for the DSI driver to access the control interface.
> >>>
> >>>Okay.
> >>>
> >>>Although, I'm not sure about the HDMI encoder example. An HDMI
> >>>encoder would read off edid directly from the adapter(with an address
> >>>specified), it wouldn't need to create an i2c client device. Therefore,
> >>>an HDMI encoder wouldn't need to have a separate node for i2c in DT.
> >>>
> >>>>
> >>>>>We can do without dummy dsi devices with this method. But, representing
> >>>>>a device with 2 DT nodes seems a bit off. We'd also need to compatible
> >>>>>strings for the same device, one for the i2c part, and the other for
> >>>>>the dsi part.
> >>>>
> >>>>I agree that this somewhat stretches the capabilities of device tree.
> >>>>Another alternative I guess would be to not have a compatible string for
> >>>>the I2C device at all (that's technically not valid, I guess) because we
> >>>>really don't need an I2C driver for the device. What we really need is a
> >>>>DSI driver with a means to talk over some I2C bus with some other part
> >>>>of its device.
> >>>
> >>>I think what the driver should 'really' be is a bit subjective, and can
> >>>vary based on what the buses are used for in the device. For the Toshiba
> >>>chip that Jani mentioned, it tends more towards a DSI driver. Whereas,
> >>>for an ADV75xx chip, it's closer to an I2C driver since only I2C can be
> >>>used to configure the chip registers.
> >>>
> >>>Although, I agree with the point you made about the DSI bus here:
> >>>
> >>>"and the DSI interface may even be crippled, but the device is still
> >>>addressable from the DSI host controller, if for nothing else than for
> >>>routing the video stream."
> >>>
> >>>The fact that the data on the DSI bus contains routing information (i.e,
> >>>virtual channel number) always gives it some 'control' aspect.
> >>>
> >>>>
> >>>>> From an adv75xx driver perspective, it should also support the ADV7511
> >>>>>chip, which is a RGB/DPI to HDMI encoder. For adv7511, we don't need a
> >>>>>DSI DT node. It would be a bit inconsistent to have the bindings
> >>>>>require both DSI and I2C nodes for one chip, and only I2C node for the
> >>>>>other, with both chips being supported by the same driver.
> >>>>
> >>>>Why would that be inconsistent? That sounds like the most accurate
> >>>>representation of the hardware to me.
> >>>
> >>>Inconsistent wasn't the right term. I should have used 'uncommon' :)
> >>>It's common for two chips of the same family to have a different set
> >>>optional properties in DT, but it's not common for two chips of the
> >>>same family to be represented by a different number of devices in
> >>>DT.
> >>>
> >>>I don't have an issue with the fused approach you suggested, as long
> >>>as people are okay with the DT parts. Especially the part of needing 2
> >>>compatible strings in the DT.
> >>
> >>I implemented the ADV7533 driver with the approach you suggested above
> >>(2 drivers for 2 different components of the chip). I posted it out
> >>just a while back (with you in loop).
> >>
> >>The DT node with this apporach would look like this:
> >>
> >>https://github.com/boddob/linux/blob/c24cbf63a6998d00095c10122ce5e37b764c7dba/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi#L162
> >>
> >>The main irritant with the '2 driver' approach is that we need to
> >>share the per-device driver data with them. For ADV7533, I've made
> >>the i2c driver allocate driver data (struct adv7511).
> >>
> >>The dsi driver gets the driver data in the following way:
> >>
> >>- The i2c driver sets the driver data as its client data using
> >>i2c_set_clientdata()
> >>- Parse the i2c-control phandle to get the corresponding i2c client.
> >>- Extract the adv7511 struct by getting i2c_get_clientdata()
> >>
> >>This way of getting the same driver data is a bit strange, but it
> >>works. For this, we do need to ensure that the dsi driver defers
> >>as long as the i2c driver isn't probed.
> >>
> >>I've now implemented both approaches for the driver. The first using
> >>a dummy dsi device, and this one using 2 drivers (with both being
> >>represented in DT). The advantage of the latter is that we don't need
> >>to create any dummy device stuff, the disadvantage is that DT is a bit
> >>uncommon.
> >>
> >>Can we now come to a conclusion on what approach is better?
> >
> >DSI by design is data bus which can be used additionally as a control bus,
> >but
> >in this particular case it is purely data bus. So of-graph bindings seem to
> >be
> >better choice. As already Lucas Stach said DT hierarchy should describe
> >control
> >buses and of-graph bindings should describe data bus. Argument that hw has
> >two
> >interfaces does not seem to be valid here - it has only one control
> >interface.
> >The other one is only for data, representing every data interface using DT
> >hierarchy would lead to inflation of pseudo devices.
> >
> >On the other side I do not see dummy device approach ideal solution, I guess
> >lightweight framework providing DSI hosts detached from Linux device model
> >could
> >work better here.
> >The only problem here is that it should coexist somehow with dsi bus used to
> >control devices. Anyway implementing it shouldn't be hard, question is if it
> >would be eventually accepted :) I guess we can live for now with dummy devs.
> >
> >Summarizing I would prefer version with dummy devices, as it seems more
> >compatible with DT design.
>
> Thanks for the feedback. I'll spin a newer version of the dummy dsi dev
> patches after waiting for some more comments.
Let's wait for someone from the device tree maintainers to comment
instead of going around in circles.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150910/dd5015ec/attachment.sig>
Op 08-09-15 om 15:26 schreef Thierry Reding:
> From: Thierry Reding
>
> These functions are like drm_modeset_{,un}lock_all(), but they take the
> lock acquisition context as a parameter rather than storing it in the
> DRM device's drm_mode_config structure.
>
> Implement drm_modeset_{,un}lock_all(
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150910/1fb34e28/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150910/b40e5339/attachment.html>
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150910/4110513f/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150910/057e2c4e/attachment.html>
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150910/22701924/attachment.html>
45 matches
Mail list logo
