Plan to support Rockchip VPU in DRM, is it a good idea
mented by anybody. One way, perhaps, might be to look at the data and see if there is any header, or not. Then parse the header if it is present, otherwise don't. > The request data may quite different from vendor to vendor, even chip to > chip. By "request data" and "chip to chip" I assume you mean the initialization of a video chip, or something analogous or similar. Believe it or not, this kind of problem has been seen before and dealt with. Look at drivers/media/usb/gspca/mr97310a.c for an example. The exact problem that we faced was that different cameras had the same USB controller chip (and therefore shared a USB vendor:product code), but they had different sensor chips with different initialization sequences. The camera vendors merely slipped a Windows driver CD into each package, and sometimes they grabbed the wrong CD, too. Evidence of that was that Google used to give a lot of links to complaints about needing a functioning Windows driver for certain cheap cameras. Unless things have changed, the Linux driver for these cameras is the only one in existence for any operating system which will tell these cameras apart and send the right initialization sequence. Moreover, the method for detecting the chipset was completely undocumented by the manufacturers, who did not even acknowledge requests for information. It is impossible to make a common way to send those settings to > driver.For the samsung MFC, you don't need to do any parse work at all. Then, as I said, you need to write driver code which will know one of them from another. Surely you can do this. Even though I continue to subscribe to the linux-media list and read with interest much of what I receive, I have not written much code for several years. I have two excuses. First, I am 75 years old now. Second, I have a full-time job doing something else. But you work for a chip vendor. Thus on the one hand you and your company are certainly deserving of praise for troubling yourselves to communicate with Linux kernel developers at all. There are those who do not (see above for an example). But on the other hand you are dealing with very experienced people, who have written a lot of code and have done a lot of plannihg about what should go where in what is now a huge mass of kernel code, and who are rightly concerned that this code should be accessible and maintainable by someone else when they are gone from the scene. I am not one of the main developers here, so perhaps you will be more willing to take it from me if I say that you and your company need to take seriously what those main developers are telling you. They have their reasons, and their reasons are very good reasons. Theodore Kilgore > Anyway, I would like to follow what Intel does now, we are both stateless > video processor. >> >> Regards, >> >> Hans >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > > -- > Randy Li > The third produce department > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Mon, 18 Oct 2010, Steven Rostedt wrote: > On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote: > > On Tue, Oct 19, 2010 at 12:24 PM, Greg KH wrote: > > > > So, there is no need for the i830 driver? Can it just be removed > > > because i915 works instead? > > > > No because it provides a different userspace ABI to the i915 driver to > > a different userspace X driver etc. > > > > like I'm sure the intersection of this driver and reality are getting > > quite limited, but its still a userspace ABI change and needs to be > > treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the > > old driver/API. > > Thus, you are saying that this will break for people with older user > apps and have a newer kernel? > > > > > >> So it really only leaves the problem case of what do distros do if we > > >> mark things as BROKEN_ON_SMP, since no distro builds UP kernels and > > >> when you boot the SMP kernels on UP they don't run as SMP so not > > >> having the driver load on those is a problem. Maybe we just need some > > >> sort of warn on smp if a smp unfriendly driver is loaded and we > > >> transition to SMP mode. Though this sounds like either (a) something > > >> we do now and I don't about it, (b) work. > > > > > > So you are saying that just because distros will never build such a > > > thing, we should keep it building for SMP mode? Why not prevent it from > > > being built and if a distro really cares, then they will pony up the > > > development to fix the driver up? > > > > Distros build the driver now even it it didn't work on SMP it wouldn't > > matter to the 99% of people who have this hw since it can't suppport > > SMP except in some corner cases. So not building for SMP is the same > > as just throwing it out of the kernel since most people don't run > > kernel.org kernels, and shouldn't have to just to get a driver for > > some piece of hardware that worked fine up until now. > > Ah! Exactly! Thus, those that do not run kernel.org kernels are using a > distro kernel. Wont these same people use the distro userspace? That is, > if they have upgraded their kernel, most likely, they also update their > X interface. > > > > > Look at this from a user who has this hardware pov, it works for them > > now with a distro kernel, us breaking it isn't going to help that user > > or make any distro care, its just going to screw over the people who > > are actually using it. > > But they can use the i915 driver instead, because they are using the > newer userspace apps. > > > > > > In other words, if someone really cares, then they will do the work, > > > otherwise why worry? Especially as it seems that no one here is going > > > to do it, right? > > > > Well the thing is doing the work right is a non-trivial task and just > > dropping support only screws the people using the hardware, > > it doesn't place any burden on the distro developers to fix it up. If > > people are really serious about making the BKL go away completely, I > > think the onus should be on them to fix the drivers not on the users > > who are using it, like I'm guessing if this gets broken the bug will > > end up in Novell or RH bugzilla in a year and nobody will ever see it. > > Well the problem comes down to testing it. I don't know of any developer > that is removing the BKL that actually owns hardware to test out these > broken drivers. And for the change not being trivial, means that there's > no way to do in correctly. > > -- Steve I might be able to find some hardware still lying around here that uses an i810. Not sure unless I go hunting it. But I get the impression that if the kernel is a single-CPU kernel there is not any problem anyway? Don't distros offer a non-smp kernel as an installation option in case the user needs it? So in reality how big a problem is this? Theodore Kilgore
Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
On Mon, 18 Oct 2010, Steven Rostedt wrote: On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote: On Tue, Oct 19, 2010 at 12:24 PM, Greg KH g...@kroah.com wrote: So, there is no need for the i830 driver? Can it just be removed because i915 works instead? No because it provides a different userspace ABI to the i915 driver to a different userspace X driver etc. like I'm sure the intersection of this driver and reality are getting quite limited, but its still a userspace ABI change and needs to be treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the old driver/API. Thus, you are saying that this will break for people with older user apps and have a newer kernel? So it really only leaves the problem case of what do distros do if we mark things as BROKEN_ON_SMP, since no distro builds UP kernels and when you boot the SMP kernels on UP they don't run as SMP so not having the driver load on those is a problem. Maybe we just need some sort of warn on smp if a smp unfriendly driver is loaded and we transition to SMP mode. Though this sounds like either (a) something we do now and I don't about it, (b) work. So you are saying that just because distros will never build such a thing, we should keep it building for SMP mode? Why not prevent it from being built and if a distro really cares, then they will pony up the development to fix the driver up? Distros build the driver now even it it didn't work on SMP it wouldn't matter to the 99% of people who have this hw since it can't suppport SMP except in some corner cases. So not building for SMP is the same as just throwing it out of the kernel since most people don't run kernel.org kernels, and shouldn't have to just to get a driver for some piece of hardware that worked fine up until now. Ah! Exactly! Thus, those that do not run kernel.org kernels are using a distro kernel. Wont these same people use the distro userspace? That is, if they have upgraded their kernel, most likely, they also update their X interface. Look at this from a user who has this hardware pov, it works for them now with a distro kernel, us breaking it isn't going to help that user or make any distro care, its just going to screw over the people who are actually using it. But they can use the i915 driver instead, because they are using the newer userspace apps. In other words, if someone really cares, then they will do the work, otherwise why worry? Especially as it seems that no one here is going to do it, right? Well the thing is doing the work right is a non-trivial task and just dropping support only screws the people using the hardware, it doesn't place any burden on the distro developers to fix it up. If people are really serious about making the BKL go away completely, I think the onus should be on them to fix the drivers not on the users who are using it, like I'm guessing if this gets broken the bug will end up in Novell or RH bugzilla in a year and nobody will ever see it. Well the problem comes down to testing it. I don't know of any developer that is removing the BKL that actually owns hardware to test out these broken drivers. And for the change not being trivial, means that there's no way to do in correctly. -- Steve I might be able to find some hardware still lying around here that uses an i810. Not sure unless I go hunting it. But I get the impression that if the kernel is a single-CPU kernel there is not any problem anyway? Don't distros offer a non-smp kernel as an installation option in case the user needs it? So in reality how big a problem is this? Theodore Kilgore ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
