<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
pinchartl: <u>hverkuil</u>: just read that the freescale kernel still uses the intdev API -_-'
hverkuil: Yeah, that's why it's so important to get Steve Longerbeam's work in the kernel to replace that crap.
<br> Freescale doesn't seem to be maintaining that code anymore.
<br> or certainly have no interest in updating it.
larsc: well, if it works!
hverkuil: <u>larsc</u>: it doesn't.
larsc: <u>hverkuil</u>: it works 'good enough' for them apparently
hverkuil: Not for some of their customers. The work on new drivers isn't being done for no reason.
<br> Besides, the code is really exceptionally bad :-)
<br> and of course can't be upgraded to a newer kernel.
larsc: I know, the stuff is absolutely horrible
<br> and all code is application specific
<br> new application same part? new driver!
pinchartl: <u>mchehab</u>: any opinion on the last iteration of the media entity types patch series ?
mchehab: not yet. I'll look on it likely later today.
hverkuil: <u>mchehab</u>: pinchartl: can someone repost the latest proposal, because I have lost the plot. Too many replies to replies to replies to....
mchehab: btw, any opinion with regards to the connectors documentation patch: https://patchwork.linuxtv.org/patch/33287/?
pinchartl: <u>hverkuil</u>: proposal for what, media entity types or connectors ?
hverkuil: Both :-)
mchehab: <u>hverkuil</u>: will send in a few
pinchartl: <u>mchehab</u>: I haven't replied to that patch specifically as I explained in my last reply yesterday night in the mail thread why I think we're not there yet and more work is needed. the patch doesn't solve the problem in my opinion, we still have no way to represent connectors that can be considered stable from a userspace point of view
hverkuil: My problem is that I can't spend as much time on this as I want, so having periodic patch series to refer to helps a lot to see the latest version so I know what we're all referring to.
mchehab: are you kidding?
pinchartl: <u>hverkuil</u>: "[PATCH v3 0/8] media: Add entity types" sent to the list two days ago. 8 patches, no reply yet, so I don't think it requires a repost only two days later :-)
<br> <u>mchehab</u>: I assume the question is addressed to me, and no, I'm not kidding
hverkuil: OK, so it's about that patch series. Good to know.
mchehab: <u>hverkuil</u>: sent
hverkuil: <u>mchehab</u>: thanks!
mchehab: https://patchwork.linuxtv.org/patch/33323/
pinchartl: <u>hverkuil</u>: let me know if you have any comment on that series, it has both your patches and mine. the patches that add device_caps to video_device can go through your tree earlier than the rest of the series as far as I'm concerned
mchehab: <u>pinchartl</u>: it seems you're. All we need to agree is about the name and the documentation, as I explained you on my last reply
<br> we don't need to address complex connectors yet... jsut composite, rf, and s-video
<br> (and only s-video with s-video signal on it)
<br> it is all 1:1 mapping
<br> your replies were just diverging from the question to be answered
hverkuil: <u>mchehab</u>: thanks for resending that patch. I think something weird happened because I don't think I ever got the original (or it was under a different subject line)
pinchartl: <u>mchehab</u>: I don't agree. my replies tried to solve the problem of how to represent connectors in MC
hverkuil: It has my ack, so I must have seen it...
mchehab: <u>hverkuil</u>: it was under a different subject line, but you acked it
pinchartl: that's not a problem we can split in small independent pieces
<br> the connector functions, as proposed now, are a little piece of the problem
<br> but they're not standalone
mchehab: <u>hverkuil</u>: that's the original one: https://patchwork.linuxtv.org/patch/33287/
pinchartl: they're part of a bigger solution
<br> we can't get them right if we don't decide how to represent connectors
<br> we haven't even agreed on whether "conn" means connector or connexion, and haven't defined what connexion means
mchehab: <u>pinchartl</u>: can't you agree that a S-video, a RF and a Composite connector is a single entity????
pinchartl: as Sakari mentioned, if we want to represent connectors, there's no such think as a s-video, RF or composite connector. we have mini-din4, bnc and rca commonly used for that purpose
<br> this is not how to design a userspace API
mchehab: <u>pinchartl</u>: what's your proposal?
pinchartl: you don't force it bit by bit hoping that noone will notice
<br> it has to be designed and address the problems being pointed out
<br> that's the normal process
mchehab: <u>pinchartl</u>: this is what we're trying to do
pinchartl: but that's not what we have done so far
mchehab: if you have a better proposal, answer with your proposal
<br> it is
<br> if a patch is not ok, one should reply with the corrections to it
pinchartl: why am I supposed to do your work ? :-) if I send a patch and receives a reply pointing out issues, I'm supposed to solve the issues and make a new proposal. I won't ask the reviewer to do my work
<br> I can certainly help
mchehab: well, then reply to the patch pointing the issues there
pinchartl: I've sent a long reply yesterday, it points out lots of issues
<br> I can send the same mail in reply to the patch too, but I doubt that would help
mchehab: <u>pinchartl</u>: just like sailus e-mail, you're contradicting yourself on your email... sometimes defending to do a 1:1 map for physical connectors and sometimes saying the opposite
<br> if you can't make up your mind about that, you can't really point to a direction
pinchartl: it's brainstorming, I'm pointing out several options and trying to outline pros and cons of them in order to move forward. it's not a proposal for a full solution
mchehab: the points you raised are interesting when mapping complex connectors like HDMI and DVI, but hardly for RF, composite, s-video
pinchartl: HDMI and DVI don't seem very complex to me, the most difficult issue is multiplexed analog connectors
mchehab: also, we all agreed on our connectors meeting on irc that we won't be mapping connectors by their physical type
pinchartl: how can I be expected to ack a proposal for RF, composite and s-video connectors if I don't have a clear picture of how we're going to represent connectors in general, and thus can't see if the proposal fits in it ?
mchehab: it doesn't make sense to use "mini-din4, bnc and rca commonly used for that purpose"
<br> as you're prpoposing today
pinchartl: it's like sending patches one line at a time, asking people to review the lines individually
<br> they're neither good nor bad, you need to see the full picture in order to review something
mchehab: well, ITU had this philosophy years ago: they rise questions to be answered, and those questions would go to a workgroup that would have 4 years to discuss...
<br> this is not the Kernel way
pinchartl: the kernel philosophy is to upstream APIs when they're ready
<br> clearly, this one isn't
mchehab: recap what it was done:
<br> we discussed and agreed about the need of connectors...
pinchartl: ask the rt-prempt developers how long they have been working on it
hverkuil: and sometimes that takes 4 years or more...
mchehab: patches for them were added last year, passed to a 7 months review period (with is a way larger than the usual kernel way)
<br> and connector support got merged
<br> now, we just need to fine tune and answer to 2 simple questions:
hverkuil: we only started really discussing connectors during that irc meeting a few weeks ago.
mchehab: 1) will we rename the names of the connector entities?
<br> 2) how to document them
pinchartl: <u>mchehab</u>: the fact that we're trying to solve the connectors issue only now shows that the patch series that got merged in v4.5-rc1 wasn't ready, sorry
mchehab: no, the fact is that every time we agree with something, you're against
<br> it is looking that you have something personal against that
pinchartl: I won't apologize for trying to make sure userspace APIs are correctly designed, I feel that's part of my duty as a kernel developer
mchehab: <u>pinchartl</u>: I'm OK to properly design the API
<br> but we can't take years to discuss every single little bit of it
<br> this is not RT... we're not changing the entire Kernel
pinchartl: MC is a significant API, especially given that we're finally extending it towards ALSA
mchehab: RT is huge because it touches every single little piece of the Kernel... removing BKL, changing mutex/semaphore code, etc
pinchartl: it's not a driver-specific ioctl for some weird device
<br> and even if it was, it still should be designed properly
mchehab: no, it isn't... and, without the work I started last year, it was far away to be accepted by ALSA
pinchartl: we've started discussing connectors two weeks ago
<br> and during those discussions it became clear that the problem is more complex than initially thought
mchehab: https://linuxtv.org/news.php?entry=2015-07-08.mchehab
<br> seek for connectors there
pinchartl: we thus can't expect to create a proper solution in a couple of days
<br> we certainly have mentioned connectors before
mchehab: sorry, https://linuxtv.org/news.php?entry=2015-11-12.mchehab
pinchartl: but we've only started tackling the problem for real two weeks ago
mchehab: gah...
<br> https://linuxtv.org/news.php?entry=2015-08-17.mchehab
<br> <u>pinchartl</u>: hdmi connectors are indeed complex, and will require lots of discussions
<br> adding support for it now would be wrong
pinchartl: analog connectors, as they can be multiplexed, seems more complex to me
mchehab: <u>pinchartl</u>: so far, among the drivers that support MC, no driver exports multiplexed connectors
<br> the only driver that has it is saa7134 (among the ones with MC)...
pinchartl: are you saying that MC should not support multiplexed analog connectors ?
mchehab: and the code doesn't currently export the "composite over s-video" mode
<br> no. I'm saying we have time to discuss that
<br> no hurry
<br> the case we need to solve is just the ones with 1:1 map
pinchartl: how can you be sure that the F_CONN function you've added to v4.5 will work in the case of multiplexed connectors ?
mchehab: one S-Video connector <=> one S-video "signal"
<br> well, we should either create a separate entity for this, or add multiple PADs to the entity
pinchartl: that's my point, we don't know what we'll do, so we don't know whether the F_CONN we have today will integrate with that or clash completely
<br> and that's what I want to avoid
mchehab: <u>pinchartl</u>: are you proposing to map this as non-entities????
<br> do you really think we would add something else?
pinchartl: it's fine developing an API piece by piece, but until we have a complete design we can't tell if it's sound and clean
mchehab: hverkuil, pinchartl: do you agree or not that a connector is an entity?
hverkuil: it is.
pinchartl: I believe connectors should be represented as entities, yes
<br> and your documentation patch documents F_CONN as connexion instead of connector
hverkuil: But what is a connector entity exactly in the case of more complex situations?
<br> <u>pinchartl</u>: you mean connection, I expect?
pinchartl: I don't think we should use entities to represent connections, at least not before defining what a connection is
<br> <u>hverkuil</u>: yes, sorry, mixing French and English :-)
hverkuil: I was wondering, what happens if we put the F_CONN defines under #ifdef __kernel__?
mchehab: <u>hverkuil</u>: it will break all PC-customer analog drivers
<br> hmm...
hverkuil: No, because they still compile. It's just userspace tools.
mchehab: the userspace tools will se an unknown entity, with is already supported
<br> yeah, this should work
hverkuil: I don't want to revert the code, but I feel we are too hurried trying to make the 4.5 deadline.
mchehab: OK, we can do that
hverkuil: I thought it was simple, but there are too many complex cases coming out of the woodwork suddenly.
pinchartl: <u>hverkuil</u>: seems to often be the case with media devices. they seem simple, but that's about where it stops :-(
<br> people writing SPI eeprom drivers don't know how lucky they are :-)
mchehab: OK, I'll not apply https://patchwork.linuxtv.org/patch/33323/, and I'll add a patch adding #if __KERNEL__ for the connector definitions
hverkuil: frankly, it's sometimes depressing. You think you're future proof, then the next weird gadget turns up that ruins all your work...
mchehab: I'll change #33323 to "under review", and let's discuss it later
hverkuil: <u>mchehab</u>: I think that's the best option. We can use the ELC to discuss this more face-to-face.
mchehab: indeed it is sometimes depressing
pinchartl: <u>hverkuil</u>: I agree. we can never prevent that. I try to do my best to cover at least the common cases
<br> <u>hverkuil</u>: mchehab: we can continue discussing it by e-mail before ELC
mchehab: works for me
pinchartl: to prepare for the mini-summit
<br> otherwise we would spend the full day on that
mchehab: yes, MC can take as many hours we have at the summits :)
pinchartl: my availability on IRC will be reduced next week as I'll attend Linaro Connect and be in the UTC+7 time zone, but e-mail will work
<br> and possibly IRC too if we can find a time convenient for everybody
hverkuil: It seems so simple when I designed it 7-8 years ago: some boxes, some links, pads and off you go into the sun!
<br> and burn down and fall to earth :-)
mchehab: except for Monday, I don't have any thing else scheduled next week
pinchartl: <u>hverkuil</u>: it took one more year developing at at Nokia with pretty much full-time work on it
hverkuil: I am available tomorrow for irc discussion.
mchehab: tomorrow is OK for me
<br> yet, I think we should keep it documented via e-mail somehow...
pinchartl: I'll fly tomorrow afternoon and I still need to pack, so tomorrow might be problematic
<br> <u>mchehab</u>: agreed
mchehab: not everybody is on IRC, and people outside might have something to contribute for
pinchartl: I'll have an internet connection in the plan though :-) at least in theory
<br> speaking of contributions, have we lost Sylwester, Tomasz, Kamil and the others ?
mchehab: I guess they're allocated to some other projects :(
pinchartl: that's a shame
mchehab: there were several changes on the second half of the last year
<br> indeed
hverkuil: <u>shuah</u>: I am really sorry that I don't seem to be able to find time to review your patches. I wish it was otherwise, but I don't see much improvement in that situation.
<br> I just wanted to mention that, because I feel guilty...
shuah: I understand - I wish you have time though, your review is valuable. Can you review the v4l2 specific ones at least
mchehab: <u>pinchartl</u>: please ping us if you have time tomorrow to discuss
hverkuil: <u>shuah</u>: patch series v3 is the latest, right? With a v4 for patch 22/22?
shuah: <u>hverkuil</u>: I have v5 on that with just renaming sound/usb media_* to media_snd*
<br> patcv v5 22/22 i.e
hverkuil: ah yes, I see it.
pinchartl: <u>mchehab</u>: I'll let you know tomorrow morning on IRC
<br> <u>mchehab</u>: I'll have lunch with Sakari tomorrow, and we plan to go through several connector use cases. it's easier face to face with a piece of paper. we'll report on the results
<br> <u>shuah</u>: thanks for the rename
mchehab: OK, great
<br> I should reply your big connectors e-mail later today, after handling patches
pinchartl: it might be hard to believe (it certainly isn't for me :-)) but I'm not trying to impeded development :-)
shuah: <u>pinchartl</u>: No problem - it was something I thought about at some point during the development and kind of spaced out
<br> so good thing you pointed out
mchehab: <u>pinchartl</u>: as I said, I'm all for improving things and designing a good API... but I don't want to go to the ITU mistake of taking forever to have a solution
<br> the perfect solution would take forever to be implemented...
<br> and by the time we have it, we may not be needing it anymore
<br> so, we need a good solution that works for most cases, and can be adapted to fit corner cases
pinchartl: <u>mchehab</u>: I don't think it will take years. it took a long time as patches have been out without being reviewed, and that's partly my fault, but it should certainly not take a year of full-time development
mchehab: I hope not. Last year, I won't have as much time as last year to work on it
<br> I mean:
<br> *This* year, I won't have as much time as last year to work on it
<br> <u>sailus</u>: ping
sailus: <u>mchehab</u>: Pong.
<br> <u>mchehab</u>: Thanks for applying the PM patches btw.
mchehab: anytime...
<br> I still don't like patch 1, though ;)
<br> but I guess it won't cause much harm
<br> <u>sailus</u>: I'm pinging you because of the other patch series...
<br> lmml_33181_v2_2_4_media_rearrange_the_fields_in_the_g_topology_ioctl_argument.patch
<br> lmml_33184_v2_1_4_media_sanitise_the_reserved_fields_of_the_g_topology_ioctl_arguments.patch
sailus: Yes, there are comments, I remember.
mchehab: yes
sailus: I needed to find more information on this.
mchehab: what do you mean?
sailus: The struct size alignment is not very strictly defined AFAIK.
mchehab: well, we can add a __packed to the structs, to avoid troubles
sailus: I wanted to find a reference to one or more C standards, but couldn't.
mchehab: that actually makes sense at the APIs
sailus: That would be a good idea, yes.
<br> But also to align their size to the size of largest data type used in them.
<br> I'm not fully certain that's true right now, I don't remembert.
<br> s/t\././
<br> I can resend them later today, making sure the size is aligned, and removing reserved fields from the G_TOPOLOGY argument.
<br> And adding __packed.
mchehab: the packed will make sure that gcc won't try to do some weird alignments
pinchartl: isn't __packed__ discouraged for ioctl structures ?
mchehab: so, from alignment perspective, it should be safe
javier__: sailus, mchehab: I think is better to reorder the struct fields with their sizes in decreasing order
mchehab: $ git grep pack include/uapi/linux/*|wc -l
<br> 1022
javier__: but when I proposed that last year it was mentioned that it was not future proof if we later need more fields
mchehab: <u>javier__</u>: I guess we're talking about patch 1/4
sailus: <u>pinchartl</u>: Why would it be?
pinchartl: <u>pinchartl</u>: I'm not sure, some distant memory :-)
<br> <u>mchehab</u>: try grepping for __packed instead :-)
<br> looks like most of them are for structures used with network protocols
mchehab: err... actuall 345 occurrences
<br> actually
<br> there are two variants...
<br> __attribute__((packed));
<br> and __packed
sailus: Packed should be used but solely relying on packed isn't.
mchehab: one of them is not recommended...
<br> can't remember what ;)
sailus: s/t\./t the right way to go./
<br> You still have to properly align the fields for sane ABI requirements.
mchehab: I guess the recommended way is: __attribute__((packed));
<br> yes, align the fields seem a good idea for me
<br> even if we use packed
<br> pinchartl, sailus: as I said before, we actually don't need to align or pack the structs
<br> I tested using G_TOPOLOGY with both 32 and 64 bits on 64 bits machines (arm64 and x86_64), and everything works fine
<br> even with the structs unaligned
javier__: <u>mchehab</u>: I was talking about truct media_v2_topology in general, now I see that Sakari proposed the same for patch 2/4 and you mentioned adding new fields to him as well
sailus: <u>mchehab</u>: It may work for you, for now.
<br> If you use the same compiler which uses exactly the same ABI.
mchehab: <u>javier__</u>: yes, sailus's patch 2/4 is almost identical to the one you sent last year
sailus: Using another compiler might give you different results.
mchehab: <u>sailus</u>: yes, a non-GNU compiler might be doing something different
pinchartl: <u>mchehab</u>: yes, I would prefer not packing the structures
sailus: One could also ask why would someone use a different compiler than GCC. :-)
pinchartl: <u>sailus</u>: no, the ABI is defined by the C standard
mchehab: that's why I agree that it is a good idea to align the structs using the reserved fields
sailus: <u>pinchartl</u>: It isn't.
<br> You have different alignment of 64-bit types between x86 and x86-64, for instance.
<br> x86 aligns them to 4 bytes, x86-64 to 8.
pinchartl: that's different architectures, not different compilers :-)
mchehab: sailus, pinchartl: I'm not 100% sure, but guess guess this is actually defined by ARM and Intel architectural docs
sailus: <u>pinchartl</u>: That's still not the C standard.
pinchartl: <u>sailus</u>: ok, part of it is defined by the architecture ABI too
mchehab: <u>sailus</u>: it this is defined by the architectural docs, the C compiler should enforce it, or it won't work properly
<br> still, I don't see any issue on doing 64-bit alignment by hand using the reserved fields
<br> or using __attribute__((aligned(8)));
<br> (although there are only 45 occurrences of aligned attribute at uAPI)
javier__: if all fields are naturally aligned to 64-bit, then those will be aligned to 32-bit as well AFAICT
<br> IOW, we just have to make sure that if __u64 and __u32 are mixed, then for each __u64 there should be two consecutives __u32
<br> so the next __u64 is aligned and won't be implicit padding
mchehab: <u>javier__</u>: on the cases sailus addressed, what we have, instead, is a series of u32, like:
<br> struct media_v2_link {
<br> __u32 id;
<br> __u32 source_id;
<br> __u32 sink_id;
<br> __u32 flags;
sailus: mchehab, pinchartl: This isn't the most relevant reference, but as an example the compiler options may matter (from GCC docs for M68k):
mchehab: __u32 reserved[5];
<br> };
sailus: -malign-int
<br> -mno-align-int
<br> Control whether GCC aligns "int", "long", "long long", "float",
<br> "double", and "long double" variables on a 32-bit boundary
<br> (-malign-int) or a 16-bit boundary (-mno-align-int). Aligning
<br> variables on 32-bit boundaries produces code that runs somewhat
<br> faster on processors with 32-bit busses at the expense of more
<br> memory.
<br> What I'm saying we should make this as certain as reasonably possible rather than just functional in most cases.
javier__: <u>sailus</u>: yes but those are for types whose size may vary between arches
<br> but __u64 and __u32 must always be 64 and 32 bit respectively
mchehab: well, on RISC, aligning to 32 bits makes things faster
javier__: <u>sailus</u>: but yeah, I guess it depends how those types are enforced...
mchehab: <u>sailus</u>: btw, if one would use those compilation options, I bet it will break the uAPI for the code that handles ioctls...
<br> as it will transform u16 into u32
sailus: <u>mchehab</u>: It won't. The size of the types is still the same independently of that option, just the alignment is different.
<br> If you don't use __packed, the struct layout may be affected by that compiler option.
mchehab: if you have
<br> struct {
<br> _u16 field1, field2;
<br> }
<br> if you force alignment to 32 bits, it will actually do:
<br> struct {
<br> u32 field1, reserved1, field2, reserved2;
<br> ops
<br> u32 field1, field2;
<br> }
<br> breaking the ioctl
<br> (need to be checked, as maybe the types for __u16 does some tricks to fix this)
<br> s/types/typedef/
sailus: <u>mchehab</u>: If you use __packed, no. And if you don't use packed, the end result is the same than adding padding in between. It won't affect the types.
mchehab: it will, as the Kernel is likely not compiled using -malign-int
<br> yes, for sure the Kernel doesn't use malign-int
<br> so, if the Kernel header doesn't use __packed, and someone compiles userspace with malign-int, it will very likely break all ioctls that use 16 bit integers
sailus: https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes
<br> That compiler option only changes the default alignment.
<br> Ah, I only read your last comment now.
<br> I think we agree then.
<br> I'll resend the set, with the comments taken into account, ok?
mchehab: <u>sailus</u>: the problem is that gcc/glibc defines int16_t as:
<br> typedef short int int16_t;
<br> and the Kernel:
<br> typedef __s16 int16_t;
<br> using maling-int will change "short int" to use 32 bits
<br> breaking any ioctl needing it
sailus: I doubt that.
mchehab: there's no __packed or __aligned directive neither at the Kernel or at userspace
<br> for the typedefs
sailus: I have no M68k hardware around to test that so we remain ignorant.
mchehab: so, except if there's some sort of hack internally at gcc, the ioctls will break
<br> neither do I
sailus: Qemu, anyone? :-)
mchehab: well, could work...
<br> but too much trouble for a simple thing...
<br> let's just align to 64 bits like I asked :)
<br> we need reserved fields there anyway
sailus: The struct size?
<br> Yes, that's what I intended as well.
mchehab: patch 2/4 is a different discussion...
<br> javier__ and you are wanting to reorder the fields...
<br> last time we've discussed, as far as I remembered, hverkuil and me were against
<br> can't remember pinchartl's opinion
sailus: I think pinchartl suggested it originally, either by e-mail or privately. I don't remember.
<br> <u>pinchartl</u>: Ping?
mchehab: the problem with reorder is that the API will become quickly messy, as we keep adding more stuff to the struct
<br> (as I described on my answer)
sailus: I don't think it'd change much.
shuah: reorder could break ioctls - won't it
sailus: If we add stuff there, we have to have new structs for compatibility.
mchehab: no, we don't need
sailus: <u>shuah</u>: The argument struct size is different.
<br> <u>shuah</u>: Well, if we add more fields, naturally.
***: benjiG has left
shuah: right
sailus: We just can't reorder once the API is in a stable kernel.
mchehab: ioctl's with a variable number or arguments work, provided that you never reorder things at the struct...
<br> it should only grow
sailus: Agreed.
shuah: right that is what I meant
mchehab: the problem with the reorder sailus and javier__ are proposing is that we'll have things like:
sailus: But it'd be the easiest to manage the compat code if the fields are only added at the end.
mchehab: u32 num_foo, num_bar;
<br> u64 ptr_foo, ptr_bar;
<br> u32 num_foo2, reserved:
sailus: I don't have a strict opinion on that patch, if you don't like it, I'm fine dropping it.
mchehab: u64 ptr_foo2;
<br> (after adding one extra foo2 pointer)
sailus: It only affects the struct layout, there's no functional difference.
mchehab: ok. Let's drop it then. I guess this will produce a better result as we grow the struct
<br> <u>javier__</u>: are you also OK with that?
sailus: I'll resend the set w/o that patch then, in a few hours.
mchehab: ok.
<br> I already applied the other two patches
<br> (didn't push yet)
sailus: Ok.
javier__: <u>mchehab</u>: yeah I'm OK with dropping it as well, that's why I didn't push any further after you mentioned that the struct may grow
mchehab: good
<br> <u>sailus</u>: just pushed the other 2 patches
sailus: <u>mchehab</u>: Ack.
<br> I'll only resend the first one then.
mchehab: OK
<br> <u>larsc</u>: please review this patch: media: adv7180: Add of compatible strings for full family
<br> http://patchwork.linuxtv.org/patch/33198/
<br> nevermind...
<br> those strings are not documented yet at DT docs
pinchartl: <u>sailus</u>: pong
mchehab: there's a second version of it, though
<br> http://patchwork.linuxtv.org/patch/33204/
hotwings: i occassionally get "mceusb 3-1.4:1.0: Error: urb status = -32". i was told thats an EPIPE error. is this something that needs to be addressed in the mceusb driver? im using an HP usb IR receiver.
sailus: <u>pinchartl</u>: About dropping "media: Rearrange the fields in the G_TOPOLOGY IOCTL argument
<br> Are you fine with that?
mchehab: sailus, pinchartl: I'm assuming that either one of you will be handling your patches for media_ctl at the v4l-utils tree
sailus: <u>mchehab</u>: Just out of curiosity... should I have push access there? I presume not?
pinchartl: I'd prefer not, but I won't insist too much. I don't really see a reason why rearranging them would cause problems, it just saves memory
<br> <u>sailus</u>: you should ask for it
sailus: <u>mchehab</u>: Can you give me access?
mchehab: sure
sailus: <u>mchehab</u>: Obrigado! :-)
mchehab: done
<br> de nada
<br> please don't forget to update the status at patchwork after applying the patches
sailus: <u>mchehab</u>: Ack.
<br> <u>mchehab</u>: Sent.
mchehab: thanks
pinchartl: <u>mchehab</u>: do you know that your patch series broke media-ctl ?
<br> I mean the MC rework merged in v4.5-rc1
<br> it broke media-ctl --print-dot